ETSI TS 129 198-4 V4.4.0 (2002-06) 



Technical Specification 



Universal Mobile Telecommunications System (UMTS); 

Open Service Access (OS A); 
Application Programming Interface (API); 

Part 4: Call control 
(3GPP TS 29.198-04 version 4.4.0 Release 4) 




3GPP TS 29.1 98-04 version 4.4.0 Release 4 1 ETSI TS 1 29 1 98-4 V4.4.0 (2002-06) 



Reference 
RTS/TSGN-05291 98-04V440 

Keywords 
UMTS 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 



Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.org 

The present document may be made available in more than one electronic version or in print. In any case of existing or 
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 
Information on the current status of this and other ETSI documents is available at 
http://portal.etsi.org/tb/status/status.asp 

If you find errors in the present document, send your comment to: 
editor(5)etsi.fr 

Copyright Notification 



No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2002. 
All rights reserved. 

DECT™, PLUGTESTS™ and UMTS™ are Trade IVlarks of ETSI registered for the benefit of its IVIembers. 
TIPHON^" and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 
2QppTM |g g jracle Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 



ETSI 



3GPP TS 29.198-04 version 4.4.0 Release 4 



2 



ETSI TS 129 198-4 V4.4.0 (2002-06) 



Intellectual Property Rights 

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http ://webapp . etsi .org/IPR/home. asp ) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under www.etsi.org/kev . 



ETSI 



3GPP TS 29.198-04 version 4.4.0 Release 4 



3 



ETSI TS 129 198-4 V4.4.0 (2002-06) 



Contents 

Intellectual Property Rights 2 

Foreword 2 

Foreword 7 

Introduction 7 

1 Scope 9 

2 References 9 

3 Definitions and abbreviations 10 

3.1 Definitions 10 

3.2 Abbreviations 10 

4 Call Control SCF 10 

5 The Service Interface Specifications 1 1 

5 . 1 Interface Specification Format 11 

5.1.1 Interface Class 11 

5.1.2 Method descriptions 11 

5.1.3 Parameter descriptions 11 

5.1.4 State Model 11 

5.2 Base Interface 12 

5.2.1 Interface Class Iplnterface 12 

5.3 Service Interfaces 12 

5.3.1 Overview 12 

5 .4 Generic Service Interface 12 

5.4.1 Interface Class IpService 12 

6 Generic Call Control Service 13 

6. 1 Sequence Diagrams 13 

6.1.1 Additional CaUbacks 13 

6.1.2 Alarm Call 15 

6.1.3 Application Initiated Call 16 

6.1.4 Call Barring 1 18 

6.1.5 Number Translation 1 20 

6.1.6 Number Translation 1 (with callbacks) 22 

6. 1 .7 Number Translation 2 24 

6. 1 .8 Number Translation 3 26 

6.1.9 Number Translation 4 28 

6.1.10 Number Translations 30 

6.1.11 Prepaid 31 

6.1.12 Pre-Paid with Advice of Charge (AoC) 33 

6.2 Class Diagrams 36 

6.3 Generic Call Control Service Interface Classes 37 

6.3.1 Interface Class IpCallControlManager 38 

6.3.2 Interface Class IpAppCallControlManager 42 

6.3.3 Interface Class IpCall 44 

6.3.4 Interface Class IpAppCaU 49 

6.4 Generic Call Control Service State Transition Diagrams 53 

6.4. 1 State Transition Diagrams for IpCallControlManager 53 

6.4.1.1 Active State 53 

6.4.1.2 Notification terminated State 53 

6.4.2 State Transition Diagrams for IpCall 53 

6.4.2.1 Network Released State 54 

6.4.2.2 Finished State 55 

6.4.2.3 Apphcation Released State 55 

6.4.2.4 Active State 55 



ETSI 



3GPP TS 29.198-04 version 4.4.0 Release 4 



4 



ETSI TS 129 198-4 V4.4.0 (2002-06) 



6.4.2.5 1 Party in Call State 55 

6.4.2.6 2 Parties in Call State 55 

6.5 Generic Call Control Service Properties 56 

6.5.1 List of Service Properties 56 

6.5.2 Service Property values for the CAMEL Service Environment 56 

6.6 Generic Call Control Data Definitions 58 

6.6. 1 Generic Call Control Event Notification Data Definitions 58 

6.6.1.1 TpCallEventi^Jame 58 

6.6.1.2 TpCallNotificationType 59 

6.6. 1 .3 TpCallEventCriteria 59 

6.6.1.4 TpCallEventlnfo 59 

6.6.2 Generic Call Control Data Definitions 59 

6.6.2.1 IpCall 59 

6.6.2.2 IpCallRef 59 

6.6.2.3 IpAppCall 60 

6.6.2.4 IpAppCallRef 60 

6.6.2.5 TpCallldentifier 60 

6.6.2.6 IpAppCaUControlManager 60 

6.6.2.7 IpAppCallControlManagerRef 60 

6.6.2.8 IpCallControlManager 60 

6.6.2.9 IpCallControlManagerRef 60 

6.6.2.10 TpCallAppInfo 60 

6.6.2.11 TpCallAppInfoType 61 

6.6.2.12 TpCallAppInfoSet 61 

6.6.2.13 TpCallEndedReport 61 

6.6.2.14 TpCallFault 61 

6.6.2.15 TpCalllnfoReport 62 

6.6.2.16 TpCallReleaseCause 62 

6.6.2.17 TpCallReport 63 

6.6.2.18 TpCallAdditionalReportlnfo 63 

6.6.2.19 TpCallReportRequest 63 

6.6.2.20 TpCallAdditionalReportCriteria 64 

6.6.2.21 TpCallReportRequestSet 64 

6.6.2.22 TpCallReportType 64 

6.6.2.23 TpCallTreatment 65 

6.6.2.24 TpCallEventCriteriaResultSet 65 

6.6.2.25 TpCallEventCriteriaResult 65 

7 MultiParty Call Control Service 65 

7 . 1 Sequence Diagrams 65 

7.1.1 Application initiated call setup 65 

7.1.2 Call Barring 2 67 

7.1.3 Call forwarding on Busy Service 68 

7. 1 .4 Call Information Collect Service 70 

7.1.5 Complex Card Service 73 

7.1.6 Hotline Service 76 

7.1.7 Use of the Redirected event 79 

7.2 Clas s Diagrams 79 

7.3 MultiParty Call Control Service Interface Classes 81 

7.3.1 Interface Class IpMultiPartyCallControlManager 81 

7.3.2 Interface Class IpAppMultiPartyCallControlManager 85 

7.3.3 Interface Class IpMultiPartyCall 88 

7.3.4 Interface Class IpAppMultiPartyCall 92 

7.3.5 Interface Class IpCallLeg 95 

7.3.6 Interface Class IpAppCallLeg 101 

7.4 MultiParty Call Control Service State Transition Diagrams 106 

7.4.1 State Transition Diagrams for IpMultiPartyCallControlManager 106 

7.4.1.1 Active State 106 

7.4. 1 .2 Interrupted State 106 

7.4.1.3 Overview of allowed methods 107 

7.4.2 State Transition Diagrams for IpMultiPartyCall 107 

7.4.2.1 IDLE State 108 



ETSI 



3GPP TS 29.198-04 version 4.4.0 Release 4 5 ETSI TS 129 198-4 V4.4.0 (2002-06) 



7.4.2.2 


ACTIVE State 


108 


7.4.2.3 


RELEASED State 


108 


7.4.2.4 




109 


7.4.3 


State Transition Diagrams for IpCallLeg 


109 


7.4.3.1 


Originating Call Leg 


109 


7.4.3.1.1 


Initiating State 


110 


7.4.3.1.2 


Analysing State 


112 


7.4.3.1.3 


Active State 


113 


7.4.3.1.4 


Releasing State 


115 


7.4.3.1.5 


Overview of allowed methods, Originating Call Leg STD 


116 


7.4.3.2 


Terminating Call Leg 


117 


7.4.3.2.1 


Idle (terminating) State 


118 


7.4.3.2.2 


Active (terminating) State 


119 


7.4.3.2.3 


Releasing (terminating) State 


121 


7.4.3.2.4 


Overview of allowed methods and trigger events, Terminating Call Leg STD 


123 


7.5 


Multi-Party Call Control Service Properties 


123 


7.5.1 


List of Service Properties 


123 


7.5.2 


Service Property values for the CAMEL Service Environment 


124 


7.6 


Multi-Party Call Control Data Definitions 


126 


7.6.1 


Event Notification Data Definitions 


126 


7.6.2 


Multi-Party Call Control Data Definitions 


126 


7.6.2.1 


IpCallLeg 


126 


7.6.2.2 


IpCallLegRef 


126 


7.6.2.3 


IpAppCallLeg 


126 


7.6.2.4 


IpAppCallLegRef 


126 


7.6.2.5 


IpMultiPartyCall 


126 


7.6.2.6 


IpMultiPartyCallRef 


126 


7.6.2.7 


Ip AppMultiPartyCall 


126 


7.6.2.8 


IpAppMultiPartyCaURef 


127 


7.6.2.9 


IpMultiPartyCallControlManager 


127 


7.6.2.10 


IpMultiPartyCallControlManagerRef 


127 


7.6.2.11 


IpAppMultiPartyCallControlManager 


127 


7.6.2.12 


IpAppMultiPartyCallControlManagerRef 


127 


7.6.2.13 


TpAppCallLegRefSet 


127 


7.6.2.14 


TpMultiPartyCallldentifier 


127 


7.6.2.15 


TpAppMultiPartyCalffiack 


127 


7.6.2.16 


TpAppMultiPartyCallBackRefType 


128 


7.6.2.17 


TpAppCallLegCallBack 


128 


7.6.2.18 


TpMultiPartyCallldentifierSet 


128 


7.6.2.19 


TpCallAppInfo 


128 


7.6.2.20 


TpCallAppInfoType 


129 


7.6.2.21 


TpCallAppInfoSet 


129 


7.6.2.22 


TpCallEventRequest 


129 


7.6.2.23 


TpCallEventRequestSet 


129 


7.6.2.24 


TpCallEventType 


130 


7.6.2.25 


TpAdditionalCallEventCriteria 


132 


7.6.2.26 


TpCallEventlnfo 


132 


7.6.2.27 


TpCallAdditionalEventlnfo 


133 


7.6.2.28 


TpCallNotificationRequest 


133 


7.6.2.29 


TpCallNotificationScope 


133 


7.6.2.30 


TpCallNotificationlnfo 


134 


7.6.2.31 


TpCallNotificationReportScope 


134 


7.6.2.32 


TpNotificationRequested 


134 


7.6.2.33 


TpNotificationRequestedSet 


134 


7.6.2.34 


TpReleaseCause 


134 


7.6.2.35 


TpReleaseCauseSet 


134 


7.6.2.36 


TpCallLegldentifier 


135 


7.6.2.37 


TpCallLegldentifierSet 


135 


7.6.2.38 




135 


7.6.2.39 


TpCallLegConnectionProperties 


135 


7.6.2.40 


TpCallLeglnf oReport 


135 


7.6.2.41 


TpCallLeglnf oType 


136 



ETSI 



3GPP TS 29.198-04 version 4.4.0 Release 4 



6 



ETSI TS 129 198-4 V4.4.0 (2002-06) 



7.6.2.42 TpCallLegSuperviseTreatment 136 

8 Common Call Control Data Types 136 

8 . 1 TpCallAlertingMechanism 136 

8.2 TpCallBearerService 137 

8.3 TpCallChargePlan 137 

8.4 TpCallPartyToChargeAdditionallnfo 1 37 

8.5 TpCallPartyToChargeType 138 

8.6 TpCaUChargeOrder 138 

8.7 TpCallChargeOrderCategory 138 

8.8 TpCallEndedReport 138 

8.9 TpCallError 138 

8.10 TpCallAdditionalErrorlnfo 139 

8.11 TpCallErrorType 139 

8.12 TpCalllnfoReport 139 

8.13 TpCalllnfoType 140 

8.14 TpCallLoadControlMechanism 140 

8.15 TpCallLoadControlIntervalRate 140 

8.16 TpCallLoadControlMechamsmType 140 

8.17 TpCaUMonitorMode 140 

8.18 TpCallNetworkAccessType 141 

8.19 TpCallPartyCategory 141 

8.20 TpCallServiceCode 141 

8.21 TpCallServiceCodeSet 141 

8.22 TpCallServiceCodeType 142 

8.23 TpCallSuperviseReport 142 

8.24 TpCallSuperviseTreatment 142 

8.25 TpCallTeleService 143 

8.26 TpCallTreatment 143 

8.27 TpCallTreatmentType 144 

8.28 TpCallAdditionalTreatmentlnfo 144 

8.29 TpMediaType 144 

Annex A (normative): OMG IDL Description of Call Control SCF 145 

Annex B (informative): Change history 146 

History 147 



ETSI 



3GPP TS 29.198-04 version 4.4.0 Release 4 



7 



ETSI TS 129 198-4 V4.4.0 (2002-06) 



Foreword 

This Technical Specification has been produced by the 3"* Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 
where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 

The present document is part 4 of a multi-part TS covering the 3"* Generation Partnership Project: Technical 
Specification Group Core Network; Open Service Access (OSA); Application Programming Interface (API), as 
identified below. The API specification (3GPP TS 29.198) is structured in the following Parts: 



Part 1: Overview 

Part 2: Common Data Definitions 

Part 3: Framework 

Part 4: Call Control SCF 

Part 5: User Interaction SCF 

Part 6: Mobility SCF 

Part 7: Terminal Capabilities SCF 

Part 8: Data Session Control SCF 

Part 9: Generic Messaging SCF (not part of 3GPP Release 4) 

Part 10: Connectivity Manager SCF (not part of 3GPP Release 4) 

Part 1 1 : Account Management SCF 

Part 12: Charging SCF 



The Mapping specification of the OSA APIs and network protocols (3GPP TR 29.998) is also structured as above. 

A mapping to network protocols is however not applicable for all Parts, but the numbering of Parts is kept. 
Also in case a Part is not supported in a Release, the numbering of the parts is maintained. 



Table: Overview of the OSA APIs & Protocol Mappings 29.198 & 29.998-family 



OSA API specificaS^^^^^^^^^B 


OSA A^^^^^^^^^^^^^^^^^H 


29.198-1 


Part 1 : Overview 


29.998-1 


Part 1 : Overview 


29.198-2 


Pari 2: Common Dala Delinitions 


29.998-2 


Not Applicable 


29.198-3 


Part 3: Framework 


29.998-3 


Not Applicable 


29.198-4 


Part 4: Call Control SCF 


29.998-4-1 


Subpart 1 : Generic Call Control - CAP mapping 


29.998-4-2 




29.198-5 


Part 5: User Interaction SCF 


29.998-5-1 


Subpart 1 : User Interaction - CAP mapping 


29.998-5-2 




29.998-5-3 




29.998-5-4 


Subpart 4: User Interaction - SMS mapping 


29.198-6 


Part 6: Mobility SCF 


29.998-6 


User Status and User Location - MAP mapping 


29.198-7 
29.198-8 


Part 7: Terminal Capabilities SCF 
Part 8: Data Session Control SCF 


29.998-8 


Data Session Control - CAP mapping 


29.198-9 


Part 9: Generic Messaging SCF 


29.998-9 


Not Applicable 


29.198-10 


Part 10: Connectivity Manager SCF 


^9.998-10 
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29.198-11 


Part 1 1 : Account Management SCF 


29.998-11 


Not Applicable ^^^^^^^^^B 


29.198-12 


Part 12: Charging SCF 


29.998-12 


Not Applicable 
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1 Scope 

The present document is Part 4 of the Stage 3 specification for an Application Prograniming Interface (API) for Open 
Service Access (OSA). 

The OSA specifications define an architecture that enables application developers to make use of network functionality 

through an open standardised interface, i.e. the OSA APIs. The concepts and the functional architecture for the OSA are 
contained in 3GPP TS 23.127 [3]. The requirements for OSA are contained in 3GPP TS 22.127 [2]. 

The present document specifies the Call Control Service Capability Feature (SCF) aspects of the interface. All aspects 
of the Call Control SCF are defined here, these being: 

• Sequence Diagrams 

• Class Diagrams 

• Interface specification plus detailed method descriptions 

• State Transition diagrams 

• Data definitions 

• IDL Description of the interfaces 

The process by which this task is accomplished is through the use of object modelling techniques described by the 
Unified ModelUng Language (UML). 

This specification has been defined jointly between 3GPP TSG CN WG5, ETSI SPAN 12 and the Parlay Consortium, 
in co-operation with a number of JAIN™ Community member companies. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of pubUcation, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 29.198-1 "Open Service Access; Application Progrannming Interface; Part 1: 





Overview" . 




12] 


3GPP TS 22.127: 


"Stage 1 Service Requirement for the Open Service Access (OSA) (Release 4)" 


[3] 


3GPPTS 23.127: 


"Virtual Home Environment (Release 4)". 


[4] 


3GPP TS 22.002: 


"Circuit Bearer Services Supported by a PLIVIN". 


[5] 


ISO 4217(1995): 


"Codes for the representation of currencies and funds ". 


[6] 


3GPP TS 24.002: 


"GSIVI-UMTS PubUc Land IVIobile Network (PLIVIN) Access Reference 




Configuration". 




[7] 


3GPPTS 22.003: 


"Circuit Teleservices supported by a Public Land Mobile Network (PLMN)". 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TS 29.198-1 [1] apply. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TS 29.198-1 [1] apply. 



4 Call Control SCF 

Two flavours of Call Control (CC) APIs have been included in 3GPP Release 4. These are the Generic Call Control 
(GCC) and the Multi-Party Call Control (MPCC). The GCC is the same API as was akeady present in the Release 99 
specification (TS 29.198 v3.3.0) and is in principle able to satisfy the requirements on CC APIs for Release 4. 

However, the joint work between 3GPP CN5, ETSI SPAN12 and the Parlay CC Working group with collaboration from 
JAIN has been focussed on the MPCC API. A number of improvements on CC functionahty have been made and are 
reflected in this API. For this it was necessary to break the inheritance that previously existed between GCC and 
MPCC. 

The joint CC group has furthermore decided that the MPCC is to be considered as the future base CC family and the 
technical work wUl not be continued on GCC. Errors or technical flaws will of course be corrected. 

The following clauses describe each aspect of the CC Service CapabiUty Feature (SCF). 

The order is as follows: 

• The Sequence diagrams give the reader a practical idea of how each of the SCF is implemented. 

• The Class relationships clause shows how each of the interfaces applicable to the SCF, relate to one another. 

• The Interface specification clause describes in detail each of the interfaces shown within the Class diagram part. 

• The State Transition Diagrams (STD) show transition between states in the SCF. The states and transitions are 
well-defined; either methods specified in the Interface specification or events occurring in the underlying networks 
cause state transitions. 

• The Data definitions clause show a detailed expansion of each of the data types associated with the methods within 
the classes. Note that some data types are used in other methods and classes and are therefore defined within the 
Common Data types part of this specification (29.198-2). 



The adopted call model has the following objects. 

* a call object. A call is a relation between a number of parties. The call object relates to the entire call view from the 
apphcation. E.g., the entire call will be released when a release is called on the call. Note that different applications can 
have different views on the same physical call, e.g., one application for the originating side and another application for 
the terminating side. The applications will not be aware of each other, all 'communication' between the applications will 
be by means of network signalling. The API currently does not specify any feature interaction mechanisms. 

* a call leg object. The leg object represents a logical association between a call and an address. The relationship 
includes at least the signalUng relation with the party. The relation with the address is only made when the leg is routed. 
Before that the leg object is IDLE and not yet associated with the address. 

* an address. The address logically represents a party in the call. 

* a terminal. A terminal is the end-point of the signalling and/or media for a party. This object type is currently not 
addressed. 
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The call object is used to establish a relation between a number of parties by creating a leg for each party within the 
call. 

Associated with the signalling relationship represented by the call leg, there may also be a bearer connection (e.g., in the 
traditional voice only networks) or a number (zero or more) of media channels (in multi-media networks). 

A leg can be attached to the call or detached from the call. When the leg is attached, this means that media or bearer 
channels related to the legs are connected to the media or bearer channels of the other legs that are attached to the same 
call. I.e., only legs that are attached can 'speak' to each other. A leg can have a number of states, depending on the 
signalling received from or sent to the party associated with the leg. Usually there is a limit to the number of legs that 
are in being routed (i.e., the connection is being established) or connected to the call (i.e., the connection is estabUshed). 
Also, there usually is a limit to the number of legs that can be simultaneously attached to the same call. 

Some networks distinguish between controlling and passive legs. By definition the call will be released when the 
controlling leg is released. AH other legs are called passive legs. There can be at most one controlling leg per call. 
However, there is currently no way the appUcation can influence whether a Leg is controlling or not. 

There are two ways for an application to get the control of a call. The apphcation can request to be notified of calls that 
meet certain criteria. When a call occurs in the network that meets these criteria, the application is notified and can 
control the call. Some legs will already be associated with the call in this case. Another way is to create a new call from 
the appUcation. 



5 The Service Interface Specifications 
5.1 Interface Specification Format 

This clause defines the interfaces, methods and parameters that form a part of the API specification. The Unified 
Modelling Language (UML) is used to specify the interface classes. The general format of an interface specification is 
described below. 

5.1.1 Interface Class 

This shows a UML interface class description of the methods supported by that interface, and the relevant parameters 
and types. The Service and Framework interfaces for enterprise-based client applications are denoted by classes with 
name Ip<name>. The callback interfaces to the applications are denoted by classes with name lpApp<name>. For 
the interfaces between a Service and the Framework, the Service interfaces are typically denoted by classes with name 
IpSvc<name>, while the Framework interfaces are denoted by classes with name IpFw<name> 

5.1 .2 Method descriptions 

Each method (API method "call") is described. Both synchronous and asynchronous methods are used in the API. 
Asynchronous methods are identified by a 'Req' suffix for a method request, and, if applicable, are served by 
asynchronous methods identified by either a 'Res' or 'Err' suffix for method results and errors, respectively. To handle 
responses and reports, the application or service developer must implement the relevant IpApp<name> or 
IpSvc<name> interfaces to provide the callback mechanism. 

5.1.3 Parameter descriptions 

Each method parameter and its possible values are described. Parameters described as 'in' represent those that must have 
a value when the method is called. Those described as 'out' are those that contain the return result of the method when 
the method returns. 

5.1.4 State Model 

If relevant, a state model is shown to illustrate the states of the objects that implement the described interface. 
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5.2 Base Interface 

5.2.1 Interface Class Iplnterface 

All application, framework and service interfaces inherit from the following interface. This API Base Interface does not 
provide any additional methods. 

«lnterface» 
Iplnterface 



5.3 Service Interfaces 
5.3.1 Overview 

The Service Interfaces provide the interfaces into the capabilities of the underlying network - such as call control, user 
interaction, messaging, mobility and connectivity management. 

The interfaces that are implemented by the services are denoted as 'Service Interface'. The corresponding interfaces that 
must be implemented by the application (e.g. for API callbacks) are denoted as 'Application Interface'. 

5.4 Generic Service Interface 
5.4.1 Interface Class IpService 

Inherits from: Iplnterface 

All service interfaces inherit from the following interface. 

«lnterface» 
IpService 



setCallback (applnterface : in IplnterfaceRef) : void 

setCallbackWitlnSessionlD (applnterface : in IplnterfaceRef, sessionID : in TpSessionID) : void 



Method 

setCallback 

This method specifies the reference address of the callback interface that a service uses to invoke methods on the 
application. It is not allowed to invoke this method on an interface that uses SessionlDs. 
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Parameters 

applnterf ace : in IpInterfaceRef 

Specifies a reference to the application interface, which is used for callbacks 

Raises 

TpCommonExceptions , P_INVALID_INTERFACE_TYPE 



Method 

setCallbackWithSessionID () 

This method specifies the reference address of the application's callback interface that a service uses for interactions 
associated with a specific session ID: e.g. a specific call, or call leg. It is not allowed to invoke this method on an 
interface that does not use SessionlDs. 

Parameters 

applnterface : in Iplnterf aceRef 

Specifies a reference to the application interface, which is used for callbacks 

sessionID : in TpSessionID 

Specifies the session for which the service can invoke the appUcation's callback interface. 

Raises 

TpCommonExceptions, P_INVALID_SESSION_ID, P_INVALID_INTERFACE_TYPE 



6 Generic Call Control Service 

The Generic Call Control API of 3GPP Rel.4 relies on the CAMEL Service Environment (CSE) and thus some 

restrictions exist to the use of the interface. The most significant one is that there is no support for createCaU method. 
The detailed description of the supported methods and further restrictions is given in the chapter 6.5. 



6.1 Sequence Diagrams 
6.1.1 Additional Callbacks 

The following sequence diagram shows how an application can register two call back interfaces for the same set of 
events. If one of the call backs can not be used, e.g., because the apphcation crashed, the other call back interface is 
used instead. 
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first instance : (Logical 
View::lpAppLoqic) 



: lpAppCallControll\/lanager 



1 : new{) 



6: 'forward event' 



second instance : 


: IpAppCallContrcrflVlanaaer 


(Loqic... 





: IpCallControlManager 



2: enableCallNotification( 



3: new() 



4: enableCallNotifcation( 



5: callEventNotify( 



7: "call Notify resuft: failure" 



8: oallEventNotify( ) 



9: "forward event" 



1 : The first instance of the application is started on node 1 . The appHcation creates a new IpAppCallControlManager to 
handle callbacks for this first instance of the logic. 

2: The enableCallNotification is associated with an applicationlD. The call control manager uses the applicationID to 
decide whether this is the same application. 

3: The second instance of the application is started on node 2. The application creates a new 
IpAppCallControlManager to handle callbacks for this second instance of the logic. 

4: The same enableCallNotification request is sent as for the first instance of the logic. Because both requests are 
associated with the same application, the second request is not rejected, but the specified callback object is stored as an 
additional callback. 

5: When the trigger occurs one of the first instance of the application is notified. The gateway may have different 
policies on how to handle additional callbacks, e.g., always first try the first registered or use some kind of round robin 
scheme. 

6: The event is forwarded to the first instance of the logic. 

7: When the first instance of the application is overloaded or unavailable this is communicated with an exception to the 
call control manager. 

8: Based on this exception the call control manager will notify another instance of the application (if available). 
9: The event is forwarded to the second instance of the logic. 
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6.1.2 Alarm Call 

The following sequence diagram shows a 'reminder message', in the form of an alarm, being delivered to a customer as 
a result of a trigger from an application. Typically, the apphcation would be set to trigger at a certain time, however, the 
application could also trigger on events. 



: (Loaical 


: loADDCall 


View::lDADDLoaic) 





IpAppUICall 



IpCallControlManaqer 



: IpCall 



IpAppUIManaqer 



:lpUICall 



1: new(} 



2: createCall( ) 



6: 'forward event' 



11 : 'f orwatti ev ent' 



3: new() 



4: routeReq( 



5; routeRes( 



7: createUICallO 



9: 5endlnfoReq( } 



< 



release( ) 



1 0: sendinf oRes( } 



12: r6lease( ) 



D 



8: new() 



"0 



1: This message is used to create an object implementing the IpAppCall interface. 

2: This message requests the object implementing the IpCallControlManager interface to create an object 
implementing the IpCall interface. 

3: Assuming that the criteria for creating an object implementing the IpCall interface (e.g. load control values not 
exceeded) is met it is created. 

4: This message instructs the object implementing the IpCall interface to route the call to the customer destined to 
receive the 'reminder message' 

5: This message passes the result of the call being answered to its callback object. 
6; This message is used to forward the previous message to the IpAppLogic. 
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7: The application requests a new UlCall object that is associated with the call object. 
8: Assuming all criteria are met, a new UlCall object is created by the service. 

9: This message instructs the object implementing the IpUICall interface to send the alarm to the customer's call. 
10: When the announcement ends this is reported to the call back interface. 
1 1 : The event is forwarded to the application logic. 

12: The apphcation releases the UlCall object, since no further announcements are required. Alternatively, the 
appUcation could have indicated P_FINAL_REQUEST in the sendlnfoReq in which case the UlCall object would have 
been impUcitly released after the announcement was played. 

13: The appUcation releases the call and all associated parties. 



6.1 .3 Application Initiated Call 

The following sequence diagram shows an application creating a call between party A and party B. This sequence could 
be done after a customer has accessed a Web page and selected a name on the page of a person or organisation to talk 
to. 
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: IpCall 
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1 : This message is used to create an object implementing the IpAppCall interface. 

2: This message requests the object implementing the IpCaUControlManager interface to create an object 
implementing the IpCall interface. 

3: Assuming that the criteria for creating an object implementing the IpCall interface (e.g. load control values not 
exceeded) is met, it is created. 

4: This message is used to route the call to the A subscriber (origination). In the message the application request 
response when the A party answers. 

5: This message indicates that the A party answered the call. 

6: This message forwards the previous message to the application logic. 

7: This message is used to route the call to the B-party. Also in this case a response is requested for call answer or 
failure. 

8: This message indicates that the B-party answered the call. The call now has two parties and a speech connection is 
automatically estabUshed between them. 

9: This message is used to forward the previous message to the IpAppLogic. 

10: Since the application is no longer interested in controlling the call, the application deassigns the call. The call will 
continue in the network, but there will be no further communication between the call object and the appUcation. 



6.1.4 Call Barring 1 

The following sequence diagram shows a call barring service, initiated as a result of a prearranged event being received 
by the framework. Before the call is routed to the destination number, the calling party is asked for a PIN code. The 
code is accepted and the call is routed to the original called party. 
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: iDCall 






toUIManaaer 



:lpUICall 




1: This message is used by the application to create an object implementing the IpAppCallControlManager interface. 

2: This message is sent by the application to enable notifications on new call events. As this sequence diagram depicts 
a call barring service, it is likely that all new call events destined for a particular address or address range prompted for 
a password before the call is allowed to progress. When a new call, that matches the event criteria set, arrives a 
message (not shown) is directed to the object implementing the IpCallControlManager. Assuming that the criteria for 
creating an object implementing the IpCall interface (e.g. load control values not exceeded) is met, other messages (not 
shown) are used to create the call and associated call leg object. 

3: This message is used to pass the new call event to the object implementing the IpAppCallControlManager interface. 
4: This message is used to forward the previous message to the IpAppLogic. 

5: This message is used by the application to create an object implementing the IpAppCall interface. The reference to 
this object is passed back to the object implementing the IpCallControlManager using the return parameter of the 
callEventNotify. 

6; This message is used to create a new UlCall object. The reference to the call object is given when creating the 
UlCall. 

7: Provided all the criteria are fulfilled, a new UlCall object is created. 
8: The call barring service dialogue is invoked. 
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9: The result of the dialogue, which in this case is the PIN code, is returned to its callback object. 
10: This message is used to forward the previous message to the IpAppLogic. 
1 1 : This message releases the UlCall object. 

12: Assuming the correct PIN is entered, the call is forward routed to the destination party. 
13: This message passes the result of the call being answered to its callback object. 
14: This message is used to forward the previous message to the IpAppLogic 

15: When the call is terminated in the network, the appUcation will receive a notification. This notification will always 
be received when the call is terminated by the network in a normal way, the appUcation does not have to request this 
event expUcitiy. 

16: The event is forwarded to the application. 

17: The appUcation must free the caU related resources in the gateway by calling deassignCall. 



The following sequence diagram shows a simple number translation service, initiated as a result of a prearranged event 
being received by the framework. 



6.1.5 



Number Translation 1 
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View::lpAppLo. 



: IpAppCallControlManaqer 



: IpAppCall 



IpCallControlManaqer 



IpCall 



1 : new() 



2: enableCallNotification( 



3: callEventNotiV( 



4: 'forward event' 



5: new() 



6: 'translate number' 



< 





7: routeReq( ) 


1 T 






' 1 ^ 

1 1 



9: 'forward event' 



8: route Res { ) 



10: deassign(iall{ 



1: This message is used by the application to create an object implementing the IpAppCallControlManager interface. 

2: This message is sent by the application to enable notifications on new call events. As this sequence diagram depicts 
a number translation service, it is likely that only new call events within a certain address range will be enabled. When 
a new call, that matches the event criteria set in message 2, arrives a message (not shown) is directed to the object 
implementing the IpCallControlManager. Assuming that the criteria for creating an object implementing the IpCall 
interface (e.g. load control values not exceeded) is met, other messages (not shown) are used to create the call and 
associated call leg object. 

3: This message is used to pass the new call event to the object implementing the IpAppCallControlManager interface. 
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4: This message is used to forward message 3 to the IpAppLogic. 

5: This message is used by the appHcation to create an object implementing the IpAppCall interface. The reference to 
this object is passed back to the object implementing the IpCallControManager using the return parameter of message 
3. 

6: This message invokes the number translation function. 

7: The returned translated number is used in message 7 to route the call towards the destination. 
8: This message passes the result of the call being answered to its callback object 
9: This message is used to forward the previous message to the IpAppLogic. 

10: The application is no longer interested in controlling the call and therefore deassigns the call. The call will continue 
in the network, but there will be no further communication between the call object and the application. 



6.1.6 Number Translation 1 (with callbacks) 

The following sequence diagram shows a simple number translation service, initiated as a result of a prearranged event 
being received by the framework. 

For illustration, in this sequence the callback references are set explicitly. This is optional. AH the callbacks references 
can also be passed in other methods. From an efficiency point of view that is also the preferred method. The rest of the 
sequences use that mechanism. 
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View::lpAppLoqic) 



IpAppCallContrplManaqer 



IpAppCall 



IpCallControlManaqer 



IpCall 



1 : new{) 



2: enableCallNotificationi 



3: setCallback( ) 



4: callEventNotify( ) 



5: 'forward event' 



6: new() 



1: setCallbackWithSes3onlD( ) 



8: 'translate number' 



9: routeReq{ ) 



1 1 : 'forward event' 



10:roUeRes( ) 



12: deassigndalK ) 



D 



1: This message is used by the application to create an object implementing the IpAppCallControlManager interface. 

2: This message is sent by the application to enable notifications on new call events. As this sequence diagram depicts 
a number translation service, it is likely that only new call events within a certain address range will be enabled. When 
a new call, that matches the event criteria set in message 2, arrives a message (not shown) is directed to the object 
implementing the IpCallControlManager. Assuming that the criteria for creating an object implementing the IpCall 
interface (e.g. load control values not exceeded) is met, other messages (not shown) are used to create the call and 
associated call leg object. 
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3: This message sets the reference of the IpAppCallControlManager object in the CallControlManager. The 
CallControlManager reports the callEventNotify to referenced object only for enableCallNotifications that do not have a 
explicit IpAppCallControlManager reference specified in the enableCallNotification. 

4: This message is used to pass the new call event to the object implementing the IpAppCallControlManager interface. 
5: This message is used to forward message 4 to the IpAppLogic. 

6: This message is used by the application to create an object implementing the IpAppCall interface. 
7: This message is used to set the reference to the IpAppCall for this call. 
8: This message invokes the number translation function. 

9: The returned translated number is used in message 7 to route the call towards the destination. 
10: This message passes the result of the call being answered to its callback object 
1 1 : This message is used to forward the previous message to the IpAppLogic. 

12: The application is no longer interested in controlling the call and therefore deassigns the call. The call will continue 
in the network, but there will be no further conmiunication between the call object and the application. 



The following sequence diagram shows a number translation service, initiated as a result of a prearranged event being 
received by the framework. If the translated number being routed to does not answer or is busy then the call is 
automatically released. 



6.1.7 



Number Translation 2 
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1: This message is used by the application to create an object implementing the IpAppCallControlManager interface. 

2: This message is sent by the application to enable notifications on new call events. As this sequence diagram depicts 
a number translation service, it is likely that only new call events within a certain address range will be enabled. When 
a new call, that matches the event criteria, arrives a message (not shown) is directed to the object implementing the 
IpCallControlManager. Assuming that the criteria for creating an object implementing the IpCall interface (e.g. load 
control values not exceeded) is met, other messages (not shown) are used to create the call and associated call leg 
object. 

3: This message is used to pass the new call event to the object implementing the IpAppCallControlManager interface. 
4: This message is used to forward the previous message to the IpAppLogic. 

5: This message is used by the application to create an object implementing the IpAppCall interface. The reference to 
this object is passed back to the object implementing the IpCallControlManager using the return parameter of the 
callEventNotify. 

6: This message invokes the number translation function. 

7: The returned translated number is used to route the call towards the destination. 

8: Assuming the called party is busy or does not answer, the object implementing the IpCall interface sends a callback 
in this message, indicating the unavailability of the called party. 
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9: This message is used to forward the previous message to the IpAppLogic. 
10: The appUcation takes the decision to release the call. 



6.1 .8 Number Translation 3 

The following sequence diagram shows a number translation service, initiated as a result of a prearranged event being 
received by the framework. If the translated number being routed to does not answer or is busy then the call is 
automatically routed to a voice mailbox. 
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1: This message is used by the application to create an object implementing the IpAppCallControlManager interface. 

2: This message is sent by the application to enable notifications on new call events. As this sequence diagram depicts 
a number translation service, it is likely that only new call events within a certain address range will be enabled. When 
a new call, that matches the event criteria, arrives a message (not shown) is directed to the object implementing the 
IpCallControlManager. Assuming that the criteria for creating an object implementing the IpCall interface (e.g. load 
control values not exceeded) is met, other messages (not shown) are used to create the call and associated call leg 
object. 
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3: This message is used to pass the new call event to the object implementing the IpAppCaUControIManager interface. 
4: This message is used to forward the previous message to the IpAppLogic. 

5: This message is used by the application to create an object implementing the IpAppCall interface. The reference to 
this object is passed back to the object implementing the IpCallControlManager using the return parameter of the 
callEventNotify. 

6: This message invokes the number translation function. 

7: The returned translated number is used to route the call towards the destination. 

8: Assuming the called party is busy or does not answer, the object implementing the IpCall interface sends a callback, 
indicating the unavailability of the called party. 

9: This message is used to forward the previous message to the IpAppLogic. 

10: The appUcation takes the decision to translate the number, but this time the number is translated to a number 
belonging to a voice mailbox system. 

11: This message routes the call towards the voice mailbox. 

12: This message passes the result of the call being answered to its callback object. 

13: This message is used to forward the previous message to the IpAppLogic. 

14: The application is no longer interested in controlling the call and therefore deassigns the call. The call will continue 
in the network, but there will be no further communication between the call object and the application. 



The following sequence diagram shows a number translation service, initiated as a result of a prearranged event being 
received by the framework. Before the call is routed to the translated number, the application requests for all call related 
information to be deUvered back to the application on completion of the call. 



6.1.9 
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1: This message is used by the application to create an object implementing the IpAppCallControlManager interface. 

2: This message is sent by the application to enable notifications on new call events. As this sequence diagram depicts 
a number translation service, it is likely that only new call events within a certain address range will be enabled. When 
a new call, that matches the event criteria, arrives a message (not shown) is directed to the object implementing the 
IpCallControlManager. Assuming that the criteria for creating an object implementing the IpCall interface (e.g. load 
control values not exceeded) is met, other messages (not shown) are used to create the call and associated call leg 
object. 

3: This message is used to pass the new call event to the object implementing the IpAppCallControlManager interface. 
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4: This message is used to forward the previous message to the IpAppLogic. 

5: This message is used by the application to create an object implementing the IpAppCall interface. The reference to 
this object is passed back to the object implementing the IpCallControlManager using the return parameter of the 
callEventNotify. 

6: This message invokes the number translation function. 

7: The application instructs the object implementing the IpCall interface to return all call related information once the 
call has been released. 

8: The returned translated number is used to route the call towards the destination. 

9: This message passes the result of the call being answered to its callback object. 
10: This message is used to forward the previous message to the IpAppLogic. 

11: Towards the end of the call, when one of the parties discormects, a message (not shown) is directed to the object 
implementing the IpCall. This causes an event, to be passed to the object implementing the IpAppCall object. 

12: This message is used to forward the previous message to the IpAppLogic. 

13: The application now waits for the call information to be sent. Now that the call has completed, the object 
implementing the IpCall interface passes the call information to its callback object. 

14: This message is used to forward the previous message to the IpAppLogic 

15: After the last information is received, the apphcation deassigns the call. This will free the resources related to this 
call in the gateway. 



6.1.10 Number Translations 

The following sequence diagram shows a simple number translation service which contains a status check function, 
initiated as a result of a prearranged event being received. In the following sequence, when the apphcation receives an 
incoming call, it checks the status of the user, and returns a busy code to the calling party. 
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1: This message is used by the application to create an object implementing the IpAppCallControlManager interface. 

2: This message is sent by the application to enable notifications on new call events. As this sequence diagram depicts 
a number translation service, it is likely that only new call events within a certain address range will be enabled. 

When a new call, that matches the event criteria set in message 2, arrives a message (not shown) is directed to the object 
implementing the IpCallControlManager. Assuming that the criteria for creating an object implementing the IpCall 
interface (e.g. load control values not exceeded) is met, other messages (not shown) are used to create the call and 
associated call leg object. 

3: This message is used to pass the new call event to the object implementing the IpAppCallControlManager interface. 
4: This message is used to forward message 3 to the IpAppLogic. 

5: This message is used by the application to create an object implementing the IpAppCall interface. The reference to 
this object is passed back to the object implementing the IpCallControlManager using the return parameter of message 
3. 

6: This message invokes the status checking function. 

7: The application decides to release the call, and sends a release cause to the calling party indicating that the user is 
busy. 



6.1.11 Prepaid 

This sequence shows a Pre-paid application. 

The subscriber is using a pre-paid card or credit card to pay for the call. The application each time allows a certain 
timeslice for the call. After the timeslice, a new timeslice can be started or the application can terminate the call. In the 
following sequence the end-user will receive an announcement before his final timeslice. 
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17:sendlnfoReq( 



19: "forward event" 



18:sendl|nfoRes( ) 



20:telease() 



21 : superviseCallReq( ) 



23: "forward event: , 



22: superviseCallRes( ) 



24:release( ) 



1: This message is used by the application to create an object implementing the IpAppCallControlManager interface. 
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2: This message is sent by the appHcation to enable notifications on new call events. As this sequence diagram depicts 
a pre-paid service, it is likely that only new call events within a certain address range will be enabled. When a new call, 
that matches the event criteria, arrives a message (not shown) is directed to the object implementing the 
IpCallControManager. Assuming that the criteria for creating an object implementing the IpCall interface (e.g. load 
control values not exceeded) is met, other messages (not shown) are used to create the call and associated call leg 
object. 

3: The incoming call triggers the Pre-Paid Application (PPA). 
4: The message is forwarded to the application. 

5: A new object on the application side for the Generic Call object is created 

6: The Pre-Paid Application (PPA) requests to supervise the call. The apphcation will be informed after the period 
indicated in the message. This period is related to the credits left on the account of the pre-paid subscriber. 

7: Before continuation of the call, PPA sends all charging information, a possible tariff switch time and the call 
duration supervision period, towards the GW which forwards it to the network. 

8: At the end of each supervision period the application is informed and a new period is started. 

9: The message is forwarded to the apphcation. 

10: The Pre-Paid Application (PPA) requests to supervise the call for another call duration. 

1 1 : At the end of each supervision period the application is informed and a new period is started. 

12: The message is forwarded to the apphcation. 

13: The Pre-Paid Application (PPA) requests to supervise the call for another call duration. 

14: When the user is almost out of credit an announcement is played to inform about this. The annoimcement is played 
only to the leg of the A-party, the B-party will not hear the announcement. 

15: The message is forwarded to the apphcation. 

16: A new UlCall object is created and associated with the controlUng leg. 

17: An announcement is played to the controlling leg informing the user about the near-expiration of his credit limit. 
The B-subscriber will not hear the announcement. 

18: When the announcement is completed the application is informed. 

19: The message is forwarded to the apphcation. 

20: The apphcation releases the UlCall object. 

21: The user does not terminate so the apphcation terminates the call after the next supervision period. 

22: The supervision period ends 

23: The event is forwarded to the logic. 

24: The application terminates the call. Since the user interaction is already exphcitly terminated no 
userlnteractionFaultDetected is sent to the apphcation. 



6.1 .12 Pre-Paid with Advice of Charge (AoC) 

This sequence shows a Pre-paid application that uses the Advice of Charge feature. 

The application will send the charging information before the actual call setup and when during the call the charging 
changes new information is sent in order to update the end-user. Note: the Advice of Charge feature requires an 
apphcation in the end-user terminal to display the charges for the call, depending on the information received from the 
apphcation. 
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Prepaid : (Logical 
View::lpAppLogic) 



: IpAppCaiiControlManager 



: IpAppCall 



: IpAppUICall 



: iDCailControlManaqer 


: IpCall 







1 : new() 



4: "forward event" 

5: newQ 



2:enableCkllNotification( ) 



3: c^llEventNotify( 



1 


II 1 1 
6: setAdviceOfCharge( i) i i 




7: supeiiviseCallReql i) i 




8i:routeReq( i) i 




' \ \ \ ^0 

1 9: superviseCallRes( ) 



1 : "forward event" 



13: "forwar^ event" 



< 



17: "fon/vard event" 



18:new() 



23: "forward ej/ent" 



26: "forward event: 



1 [I : superviseCallReb( 



12:superviseCa|lRes( ) 



l4:setAdviceOfCtiar^e( 



15: superviseCallReq( ) 
16: superviseCallRes( ) 



19lcreateUICall( ) 



21:sendlnfoReq( i ) 



22 : send In lb Res ( 



^4:superviseCallR^q( 



25: superviseCillRes( 



27: release( ) 



> 



28: userlnteractionFaultDetected( 



IpUIManaqer : IpUICall 



20: new() 
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1 : This message is used by the application to create an object implementing the IpAppCallControlManager interface. 

2: This message is sent by the application to enable notifications on new call events. As this sequence diagram depicts 
a pre-paid service, it is likely that only new call events within a certain address range will be enabled. When a new call, 
that matches the event criteria, arrives a message (not shown) is directed to the object implementing the 
IpCallControlManager. Assuming that the criteria for creating an object implementing the IpCall interface (e.g. load 
control values not exceeded) is met, other messages (not shown) are used to create the call and associated call leg 
object. 

3: The incoming call triggers the Pre-Paid AppUcation (PPA). 

4: The message is forwarded to the application. 

5: A new object on the application side for the Call object is created 

6: The Pre-Paid Application (PPA) sends the AoC information (e.g. the tariff switch time), (it shall be noted the PPA 
contains ALL the tariff information and knows how to charge the user). 

During this call sequence 2 tariff changes take place. The call starts with tariff 1, and at the tariff switch time (e.g., 
18:00 hours) switches to tariff 2. The application is not informed about this (but the end-user is!) 

7: The Pre-Paid Application (PPA) requests to supervise the call. The appUcation will be informed after the period 
indicated in the message. This period is related to the credits left on the account of the pre-paid subscriber. 

8: The application requests to route the call to the destination address. 

9: At the end of each supervision period the appUcation is informed and a new period is started. 
10: The message is forwarded to the application. 

1 1 : The Pre-Paid Application (PPA) requests to supervise the call for another call duration. 

12: At the end of each supervision period the application is informed and a new period is started. 

13: The message is forwarded to the appUcation. 

14: Before the next tariff switch (e.g., 19:00 hours) the application sends a new AOC with the tariff switch time. Again, 
at the tariff switch time, the network will send AoC information to the end-user. 

15: The Pre-Paid Application (PPA) requests to supervise the caU for another call duration. 

16: When the user is almost out of credit an announcement is played to inform about this (19-21). The announcement is 
played only to the leg of the A-party, the B -party will not hear the announcement. 

17: The message is forwarded to the appUcation. 

18: TUe appUcation creates a new call back interface for the User interaction messages. 
19: A new UI CaU object that wUl handle playing of the announcement needs to be created 
20: The Gateway creates a new UI call object that will handle playing of the annoimcement. 
21: With this message the announcement is played to the calling party. 
22: The user indicates that the call should continue. 
23: The message is forwarded to the application. 

24: The user does not terminate so the application terminates the call after the next supervision period. 

25: The user is out of credit and the appUcation is informed. 

26: The message is forwarded to the appUcation. 

27: With this message the application requests to release the call. 
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28: Terminating the call which has still a UlCall object associated will result in a userlnteractionFaultDetected. The 
UlCall object is terminated in the gateway and no further communication is possible between the UlCall and the 
application. 



6.2 Class Diagrams 

This class diagram shows the interfaces of the generic call control service package. 



«lnterface» 
IpService 



setCallbackQ 

setCallbackWithSessionlDQ 



«lnterface» 
IpCallControlManager 

(from gees) 

♦createCallO 
♦enableCallNotificationO 
^disableCallNotificationO 
^setCallLoadControlQ 
HthangeCallNotificationQ 
'^getCriteriaQ 



0..n 



«lnterface» 
IpCall 

(from gees) 



|routeReq() 
BreleaseO 

f^eassignCallO 
j^getCalllnfoReqO 
l^setCallChargePlanO 
I ♦setAdviceOfChargeQ 
l^getMoreDialledDigitsReqO 
I u pervi s eCal I Req() 



Figure: Service Interfaces 

The generic call control service consists of two packages, one for the interfaces on the application side and one for 
interfaces on the service side. 

The class diagrams in the following figures show the interfaces that make up the generic call control application 
package and the generic call control service package. Communication between these packages is indicated with the 
«uses» associations; e.g., the IpCallControlManager interface uses the IpAppCallControlManager , by means of 
calling callback methods. 

This class diagram shows the interfaces of the generic call control application package and their relations to the 
interfaces of the generic call control service package. 
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«lnterface» 
Iplnterface 



«lnterface» 
IpAppCallControlManager 

(from gees) 



^callAbortedO 

I ^callEventNotifyO 

I ^callNotificationlnterruptedQ 

I ^callNotificationContinuedQ 

I ^callOverloadEncounteredQ 

^callOverloadCeasedQ 



«uses» 



0..n 



«lnterface» 
IpAppCall 

(from goes) 



%outeRes() 

^outeErrQ 

♦getCalllnfoResO 

♦getCalllnfoErrQ 

^superviseCallResQ 

^superviseCallErrQ 

♦callFaultDetectedQ 

^getMoreDialledDigitsResO 

^getMoreDialledDigitsErrQ 

♦callEndedQ 



^<uses>> 



«lnterface» 
IpCallControlManager 

(from gees) 


1 0..n 


«lnterface» 
IpCall 

(from gees) 









Figure: Application Interfaces 



6.3 



Generic Call Control Service Interface Classes 



The Generic Call Control Service (GCCS) provides the basic call control service for the API. It is based around a third 
party model, which allows calls to be instantiated from the network and routed through the network. 



The GCCS supports enough functionality to allow call routing and call management for today's Intelligent Network 
(IN) services in the case of a switched telephony network, or equivalent for packet based networks. 
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It is the intention of the GCCS that it could be readily specialised into call control specifications, for example, ITU-T 
recommendations H.323, ISUP, Q.931 and Q.2931, ATM Forum specification UNI3.1 and the IETF Session Initiation 
Protocol, or any other call control technology. 

For the generic call control service, only a subset of the call model defined in clause 4 is used; the API for generic call 
control does not give explicit access to the legs and the media channels. This is provided by the Multi-Party Call 
Control Service. Furthermore, the generic call is restricted to two party calls, i.e., only two legs are active at any given 
time. Active is defined here as 'being routed' or connected. 

The GCCS is represented by the IpCallControIManager and IpCall interfaces that interface to services provided by the 
network. Some methods are asynchronous, in that they do not lock a thread into waiting whilst a transaction performs. 
In this way, the client machine can handle many more calls, than one that uses synchronous message calls. To handle 
responses and reports, the developer must implement IpAppCallControIManager and IpAppCall to provide the callback 
mechanism. 

6.3.1 Interface Class IpCallControIManager 

Inherits from: IpService 

This interface is the 'service manager' interface for the Generic Call Control Service. The generic call control manager 
interface provides the management functions to the generic call control service. The application programmer can use 
this interface to provide overload control functionaUty, create call objects and to enable or disable call-related event 
notifications. 

«lnterface» 
IpCallControIManager 



createCall (appCall : in IpAppCallRef) : TpCallldentifier 

enableCallNotification (appCallControlManager : in IpAppCallControlManagerRef, eventCriteria : in 
TpCallEventCriteria) : TpAssignmentID 

disableCallNotification (assignmentID : in TpAssignmentID) : void 

setCallLoadControl (duration : in TpDuration, mechanism : in TpCallLoadControlMechanism, treatment : in 
TpCallTreatment, addressRange : in TpAddressRange) : TpAssignmentID 

changeCallNotification (assignmentID : in TpAssignmentID, eventCriteria : in TpCallEventCriteria) : void 

getCriteria () : TpCallEventCriteriaResultSet 



Method 

createCall ( ) 

This method is used to create a new call object. An IpAppCallControIManager should already have been passed to the 
IpCallControIManager, otherwise the call control will not be able to report a callAborted() 

to the application (the application should invoke setCallback() if it wishes to ensure this). 

Returns callReference: Specifies the interface reference and sessionID of the call created. 

Parameters 

appCall : in IpAppCallRef 

Specifies the appUcation interface for callbacks from the call created. 



ETSI 



3GPP TS 29.198-04 version 4.4.0 Release 4 



39 



ETSI TS 129 198-4 V4.4.0 (2002-06) 



Returns 

TpCallldentif ier 

Raises 

TpCommonExcept ions , P_INVALID_INTERFACE_TYPE 

Method 

enableCallNotif ication 

This method is used to enable call notifications so that events can be sent to the application. This is the first step an 
appUcation has to do to get initial notification of calls happening in the network. When such an event happens, the 
application will be informed by callEventNotify(). In case the application is interested in other events during the context 
of a particular call session it has to use the routeReqO method on the call object. The application will get access to the 
call object when it receives the callEventNotify(). (Note that the enableCalLNotification() is not applicable if the call is 
setup by the application). 

The enableCallNotification method is purely intended for applications to indicate their interest to be notified when 

certain call events take place. It is possible to subscribe to a certain event for a whole range of addresses, e.g. the 
application can indicate it wishes to be informed when a call is made to any number starting with 800. 

If some application already requested notifications with criteria that overlap the specified criteria, the request is refused 
with P_GCCS_INVALID_CRITERIA. The criteria are said to overlap if both originating and terminating ranges 
overlap and the same number plan is used and the same CaUNotificationType is used. 

If a notification is requested by an application with the monitor mode set to notify, then there is no need to check the 
rest of the criteria for overlapping with any existing request as the notify mode does not allow control on a call to be 
passed over. Only one application can place an interrupt request if the criteria overlaps. 

If the same appUcation requests two notifications with exactly the same criteria but different callback references, the 
second callback will be treated as an additional callback. Both notifications will share the same assignmentlD. The 
gateway will always use the most recent callback. In case this most recent callback fails the second most recent is used. 
In case the enableCallNotification contains no callback, at the moment the application needs to be informed the gateway 
will use as callback the callback that has been registered by setCallback(). 

Returns assigrmientID: Specifies the ID assigned by the generic call control manager interface for this newly-enabled 
event notification. 

Parameters 

appCallControlManager : in IpAppCallControlManagerRef 

If this parameter is set (i.e. not NULL) it specifies a reference to the application interface, which is used for callbacks. If 
set to NULL, the application interface defaults to the interface specified via the setCallback() method. 

eventCriteria : in TpCallEventCriteria 

Specifies the event specific criteria used by the application to define the event required. Only events that meet these 

criteria are reported. Examples of events are "incoming call attempt reported by network", "answer", "no answer", 
"busy". Individual addresses or address ranges may be specified for destination and/or origination. 
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Returns 

TpAs s ignmen't I D 

Raises 

TpCommonExceptions, P_INVALID_CRITERIA, P_INVALID_INTERFACE_TYPE, 
P_INVALID_EVENT_TYPE 

Method 

disableCallNotif ication 

This method is used by the application to disable call notifications. 
Parameters 

assignmentID : in TpAssignmentID 

Specifies the assignment ID given by the generic call control manager interface when the previous 
enableCallNotificationO was called. If the assigrmient ID does not correspond to one of the valid assigrmient IDs, the 
exception P_1NVAL1D_ASS1GNMENTID will be raised. If two callbacks have been registered under this assignment 
ID both of them will be disabled. 

Raises 

TpCommonExceptions , P_INVALID_ASSIGNMENT_ID 

Method 

setCallLoadControl () 

This method imposes or removes load control on calls made to a particular address range within the generic call control 
service. The address matching mechanism is similar as defined for TpCaUEventCriteria. 

Returns assigrmientID: Specifies the assigrmientID assigned by the gateway to this request. This assigimientID can be 
used to correlate the caUOverloadEncountered and callOverloadCeased methods with the request. 

Parameters 

duration : in TpDuration 

Specifies the duration for which the load control should be set. 

A duration of indicates that the load control should be removed. 

A duration of -1 indicates an infinite duration (i.e., until disabled by the application) 

A duration of -2 indicates the network default duration. 

mechanism : in TpCallLoadControlMechanism 

Specifies the load control mechanism to use (for example, admit one call per interval), and any necessary parameters, 
such as the call admission rate. The contents of this parameter are ignored if the load control duration is set to zero. 

treatment : in TpCallTreatment 

Specifies the treatment of calls that are not admitted. The contents of this parameter are ignored if the load control 
duration is set to zero. 

addressRange : in TpAddressRange 

Specifies the address or address range to which the overload control should be applied or removed. 
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Returns 

TpAs s ignment ID 

Raises 

TpCommonExceptions, P_INVALID_ADDRESS, P_UNSUPPORTED_ADDRESS_PLAN 

Method 

changeCallNotif ication 

This method is used by the application to change the event criteria introduced with enableCallNotification. Any stored 
criteria associated with the specified assignmentID will be replaced with the specified criteria. 

Parameters 

assignmen'tID : in TpAssignmen'tID 

Specifies the ID assigned by the generic call control manager interface for the event notification. If two call backs have 
been registered under this assignment ID both of them will be changed. 

eventCri'teria : in TpCallEventCri'teria 

Specifies the new set of event specific criteria used by the appUcation to define the event required. Only events that 
meet these criteria are reported. 

Raises 

TpCommonExceptions, P_INVALID_ASSIGNMENT_ID, P_INVALID_CRITERIA, 
P_INVALID_EVENT_TYPE 

Method 

getCriteria ( ) 

This method is used by the application to query the event criteria set with enableCallNotification or 
changeCallNotification. 

Returns eventCriteria: Specifies the event specific criteria used by the application to define the event required. Only 
events that meet these criteria are reported. 

Parameters 

No Parameters were identified for this method 
Returns 

TpCallEventCriteriaResultSet 

Raises 

TpCommonExceptions 
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6.3.2 Interface Class IpAppCallControlManager 

Inherits from: Iplnterface 

The generic call control manager application interface provides the application call control management functions to the 
generic call control service. 

«lnterface» 
IpAppCallControlManager 



callAborted (callReference : in TpSessionID) : void 

callEventNotify (callReference : in TpCallldentifier, eventlnfo : in TpCallEventlnfo, assignmentID : in 
TpAssignmentID) : IpAppCallRef 

callNotificationlnterrupted () : void 

callNotificationContinued () : void 

callOverloadEncountered (assignmentID : in TpAssignmentID) : void 
callOverloadCeased (assignmentID : in TpAssignmentID) : void 



Method 

callAborted ( ) 

This method indicates to the application that the call object (at the gateway) has aborted or terminated abnormally. No 
further communication will be possible between the call and application. 

Parameters 

callReference : in TpSessionID 

Specifies the sessionID of call that has aborted or terminated abnormally. 



Method 

callEventNotify ( ) 

This method notifies the application of the arrival of a call-related event. 

If this method is invoked with a monitor mode of P_CALL_MONITOR_MODE_INTERRUPT, then the APL has 
control of the call. If the APL does nothing with the call (including its associated legs) within a specified time period 
(the duration of which forms a part of the service level agreement), then the call in the network shall be released and 
callEndedO shall be invoked, giving a release cause of 102 (Recovery on timer expiry). 

When this method is invoked with a monitor mode of P_CALL_MONITOR_MODE_INTERRUPT, the application 
writer should ensure that no routeReqO is performed until an IpAppCall has been passed to the gateway, either through 
an explicit setCallback() invocation on the supplied IpCall, or via the return of the callEventNotifyO method. 

Returns appCall: Specifies a reference to the application interface which implements the callback interface for the new 
call. This parameter will be null if the notification is in NOTIFY mode. 
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Parameters 

callReference : in TpCall Identifier 

Specifies the reference to the call interface to which the notification relates. This parameter will be null if the 
notification is in NOTIFY mode. 

event Info : in TpCallEventInf o 

Specifies data associated with this event. 

assignmentID : in TpAssignmentID 

Specifies the assigrmient id which was returned by the enableCallNotification() method. The application can use 
assigimient id to associate events with event specific criteria and to act accordingly. 

Returns 

IpAppCallRef 

Method 

callNotif icationlnterrupted ( ) 

This method indicates to the apphcation that aU event notifications have been temporarily interrupted (for example, due 
to faults detected). 

Note that more permanent failures are reported via the Framework (integrity management). 
Parameters 

No Parameters were identified for this method 
Method 

callNotif icationContinued ( ) 

This method indicates to the apphcation that event notifications will again be possible. 

Parameters 

No Parameters were identified for this method 



Method 

callOverloadEncountered ( ) 

This method indicates that the network has detected overload and may have automatically imposed load control on calls 
requested to a particular address range or calls made to a particular destination within the call control service. 

Parameters 

assignmentID : in TpAssignmentID 

Specifies the assignmentID corresponding to the associated setCaULoadControl. This implies the address range for 
within which the overload has been encountered. 
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Method 

callOverloadCeased ( ) 

This method indicates that the network has detected that the overload has ceased and has automatically removed any 
load controls on calls requested to a particular address range or calls made to a particular destination within the call 
control service. 

Parameters 

assignmentID : in TpAssignmentID 

Specifies the assignmentID corresponding to the associated setCallLoadControl. This implies the address range for 
within which the overload has been ceased 



6.3.3 Interface Class IpCall 

Inherits from: IpService 

The generic Call provides the possibility to control the call routing, to request information from the call, control the 
charging of the call, to release the call and to supervise the call. It does not give the possibility to control the legs 
directly and it does not allow control over the media. The first capability is provided by the multi-party call and the 
latter as well by the multi-media call. The call is limited to two party calls, although it is possible to provide 'follow-on' 
calls, meaning that the call can be rerouted after the terminating party has disconnected or routing to the terminating 
party has failed. Basically, this means that at most two legs can be in connected or routing state at any time. 

«lnterface» 
IpCall 



routeReq (callSessionID : in TpSessionID, responseRequested : in TpCallReportRequestSet, targetAddress 
: in TpAddress, originatingAddress : in TpAddress, originalDestinationAddress : in TpAddress, 
redirectingAddress : in TpAddress, applnfo : in TpCallApplnfoSet) : TpSessionID 

release (callSessionID : in TpSessionID, cause : in TpCallReleaseCause) : void 

deassignCall (callSessionID : in TpSessionID) : void 

getCalllnfoReq (callSessionID : in TpSessionID, calllnfoRequested : in TpCalllnfoType) : void 

setCallChargePlan (callSessionID : in TpSessionID, callChargePlan : in TpCallChargePlan) : void 

setAdviceOfCharge (callSessionID : in TpSessionID, aOCInfo : in TpAoClnfo, tariffSwitch : in TpDuration) : 
void 

getMoreDialledDigitsReq (callSessionID : in TpSessionID, length : in Tplnt32) : void 

superviseCallReq (callSessionID : in TpSessionID, time : in TpDuration, treatment : in 
TpCallSuperviseTreatment) : void 
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Method 

routeReq ( ) 

This asynchronous method requests routing of the call to the remote party indicated by the targetAddress. 

Note that in case of routeReqO it is recommended to request for 'successful' (e.g. 'answer' event) and 'failure' events at 
invocation, because those are needed for the application to keep track of the state of the call. 

The extra address information such as originatingAddress is optional. If not present (i.e., the plan is set to 
P_ADDRESS_PLAN_NOT_PRESENT), the information provided in corresponding addresses from the route is used, 
otherwise the network or gateway provided numbers will be used. 

If this method in invoked, and call reports have been requested, yet no IpAppCaU interface has been provided, this 
method shall throw the P_NO_CALLBACK_ADDRESS_SET exception. 

Returns callLegSessionlD: Specifies the sessionlD assigned by the gateway. This is the sessionlD of the implicitly 
created call leg. The same ID will be returned in the routeRes or Err. This allows the apphcation to correlate the request 
and the result. 

This parameter is only relevant when multiple routeReqO calls are executed in parallel, e.g., in the multi-party call 
control service. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

responseRequested : in TpCallReportRequestSet 

Specifies the set of observed events that wUl result in zero or more routeRes() being generated. 

E.g., when both answer and disconnect is monitored the result can be received two times. 
If the apphcation wants to control the call (in whatever sense) it shall enable event reports 

targetAddress : in TpAddress 

Specifies the destination party to which the call leg should be routed. 

originatingAddress : in TpAddress 

Specifies the address of the originating (calling) party. 

originalDestinationAddress : in TpAddress 

Specifies the original destination address of the call. 

redirect ingAddress : in TpAddress 

Specifies the address from which the call was last redirected. 

applnfo : in TpCallAppInf oSet 

Specifies application-related information pertinent to the call (such as alerting method, tele-service type, service 
identities and interaction indicators). 
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Returns 
TpSessionID 

Raises 

TpCommonExceptions, P_INVALID_SESSION_ID, P_INVALID_ADDRESS , 
P_UNSUPPORTED_ADDRESS_PLAN, P_INVALID_NETWORK_STATE , P_INVALID_CRITERIA, 
P INVALID EVENT TYPE 



Method 
release () 

This method requests the release of the call object and associated objects. The call will also be terminated in the 
network. If the application requested reports to be sent at the end of the call (e.g., by means of getCalLInfoReq) these 
reports will still be sent to the application. 

The application should always either release or deassign the call when it is finished with the call, unless a 
callFaultDetected is received by the appUcation. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

cause : in TpCallReleaseCause 

Specifies the cause of the release. 

Raises 

TpCommonExceptions, P_INVALID_SESSION_ID, P_INVALID_NETWORK_STATE 

Method 

deassignCall () 

This method requests that the relationship between the application and the call and associated objects be de-assigned. It 
leaves the call in progress, however, it purges the specified call object so that the appUcation has no further control of 
call processing. If a call is de-assigned that has event reports, call information reports or call Leg information reports 
requested, then these reports will be disabled and any related information discarded. 

The application should always either release or deassign the call when it is finished with the call, unless 
callFaultDetected is received by the application. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 
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Raises 

TpCommonExcept ions , P_INVALID_SESSION_ID 

Method 

getCallInf oReq ( ) 

This asynchronous method requests information associated with the call to be provided at the appropriate time (for 
example, to calculate charging). This method must be invoked before the call is routed to a target address. 

A report is received when the destination leg or party terminates or when the call ends. The call object will exist after 
the call is ended if information is required to be sent to the application at the end of the call. In case the originating party 
is stiU available the application can stiU initiate a follow-on call using routeReq. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

callinf oRequested : in TpCalllnfoType 

Specifies the call information that is requested. 

Raises 

TpCommonExceptions , P_INVALID_SESSION_ID 

Method 

setCallChargePlan ( ) 

Set an operator specific charge plan for the call. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

callChargePlan : in TpCallChargePlan 

Specifies the charge plan to use. 

Raises 

TpCommonExceptions , P_INVALID_SESSION_ID 

Method 

setAdviceOf Charge () 

This method allows for advice of charge (AOC) information to be sent to terminals that are capable of receiving this 
information. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 
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aOCInfo : in TpAoCInfo 

Specifies two sets of Advice of Charge parameter. 

tarif fSwitch : in TpDuration 

Specifies the tariff switch interval that signifies when the second set of AoC parameters becomes valid. 

Raises 

TpCommonExceptions , P_INVALID_SESSION_ID 

Method 

getMoreDialledDigitsReq ( ) 

This asynchronous method requests the call control service to collect further digits and return them to the application. 
Depending on the administered data, the network may indicate a new call to the gateway if a caller goes off-hook or 
dialled only a few digits. The application then gets a new call event which contains no digits or only the few dialled 
digits in the event data. 

The application should use this method if it requires more dialled digits, e.g. to perform screening. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

length : in Tplnt32 

Specifies the maximum number of digits to collect. 

Raises 

TpCommonExceptions , P_INVALID_SESSION_ID 

Method 

superviseCallReq ( ) 

The application calls this method to supervise a call. The application can set a granted connection time for this call. If 
an application calls this function before it calls a routeReqO or a user interaction function the time measurement will 
start as soon as the call is answered by the B -party or the user interaction system. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

time : in TpDuration 

Specifies the granted time in milliseconds for the connection. 

treatment : in TpCallSuperviseTreatment 

Specifies how the network should react after the granted connection time expired. 
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Raises 

TpCommonExceptions , P_INVALID_SESSION_ID 



6.3.4 Interface Class IpAppCall 

Inherits from: Iplnterface 

The generic call application interface is implemented by the client application developer and is used to handle call 
request responses and state reports. 

«lnterface» 
IpAppCall 



routeRes (callSessionID : in TpSessionID, eventReport : in TpCallReport, callLegSessionID : in 
TpSessionID) : void 

routeErr (callSessionID : in TpSessionID, errorlndication : in TpCallError, callLegSessionID : in 
TpSessionID) : void 

getCalllnfoRes (callSessionID : in TpSessionID, calllnfoReport : in TpCalllnfoReport) : void 

getCalllnfoErr (callSessionID : in TpSessionID, errorlndication : in TpCallError) : void 

superviseCallRes (callSessionID : in TpSessionID, report : in TpCallSuperviseReport, usedTime : in 
TpDuration) : void 

superviseCallErr (callSessionID : in TpSessionID, errorlndication : in TpCallError) : void 
callFaultDetected (callSessionID : in TpSessionID, fault : in TpCallFault) : void 
getMoreDialledDigitsRes (callSessionID : in TpSessionID, digits : in TpString) : void 
getMoreDialledDigitsErr (callSessionID : in TpSessionID, errorlndication : in TpCallError) : void 
callEnded (callSessionID : in TpSessionID, report : in TpCallEndedReport) : void 



Method 

routeRes ( ) 

This asynchronous method indicates that the request to route the call to the destination was successful, and indicates the 
response of the destination party (for example, the call was answered, not answered, refused due to busy, etc.). 

If this method is invoked with a monitor mode of P_CALL_MONITOR_MODE_INTERRUPT, 

then the APL has control of the call. If the APL does nothing with the call (including its associated legs) within a 
specified time period (the duration of which forms a part of the service level agreement), then the call in the network 
shall be released and callEnded() shall be invoked, giving a release cause of 102 (Recovery on timer expiry). 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 
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eventReport : in TpCallReport 

Specifies the result of the request to route the call to the destination party. It also includes the network event, date and 
time, monitoring mode and event specific information such as release cause. 

callLegSessionID : in TpSessionID 

Specifies the sessionID of the associated call leg. This corresponds to the sessionID returned at the routeReqO and can 
be used to correlate the response with the request. 

Method 

routeErr ( ) 

This asynchronous method indicates that the request to route the call to the destination party was unsuccessful - the call 
could not be routed to the destination party (for example, the network was unable to route the call, the parameters were 
incorrect, the request was refused, etc.). 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

errorlndica'tion : in TpCallError 

Specifies the error which led to the original request failing. 

callLegSessionID : in TpSessionID 

Specifies the sessionID of the associated call leg. This corresponds to the sessionID returned at the routeReqO and can 
be used to correlate the error with the request. 

Method 

getCalllnfoRes () 

This asynchronous method reports time information of the finished call or call attempt as well as release cause 
depending on which information has been requested by getCalllnfoReq. This information may be used e.g. for charging 
purposes. The call information will possibly be sent after routeRes in all cases where the call or a leg of the call has 
been discormected or a routing failure has been encountered. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

callinf oReport : in TpCallInf oReport 

Specifies the call information requested. 

Method 

getCallInf oErr ( ) 

This asynchronous method reports that the original request was erroneous, or resulted in an error condition. 
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Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

errorlndication : in TpCallError 

Specifies the error which led to the original request failing. 

Method 

superviseCallRes () 

This asynchronous method reports a call supervision event to the apphcation when it has indicated its interest in these 
kind of events. 

It is also called when the connection is terminated before the supervision event occurs. Furthermore, this method is 
invoked as a response to the request also when a tariff switch happens in the network during an active call. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call 

report : in TpCallSuperviseReport 

Specifies the situation which triggered the sending of the call supervision response. 
usedTime : in TpDuration 

Specifies the used time for the call supervision (in milliseconds). 
Method 

superviseCallErr ( ) 

This asynchronous method reports a call supervision error to the application. 
Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

errorlndication : in TpCallError 

Specifies the error which led to the original request failing. 

Method 

callFaultDetected ( ) 

This method indicates to the application that a fault in the network has been detected. The call may or may not have 
been terminated. 

The system deletes the call object. Therefore, the application has no further control of call processing. No report will be 
forwarded to the application. 
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Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call in which the fault has been detected. 

fault : in TpCallFault 

Specifies the fault that has been detected. 

Method 

getMoreDialledDigitsRes () 

This asynchronous method returns the collected digits to the application. 
Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

digits : in TpString 

Specifies the additional dialled digits if the string length is greater than zero. 
Method 

getMoreDialledDigitsErr ( ) 

This asynchronous method reports an error in collecting digits to the apphcation. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

errorlndication : in TpCallError 

Specifies the error which led to the original request failing. 

Method 

callEndedO 

This method indicates to the apphcation that the call has terminated in the network. However, the application may still 
receive some results (e.g., getCalllnfoRes) related to the call. The application is expected to deassign the call object 
after having received the callEnded. 

Note that the event that caused the call to end might also be received separately if the application was monitoring for it. 
Parameters 

callSessionID : in TpSessionID 

Specifies the call sessionlD. 

report : in TpCallEndedReport 

Specifies the reason the call is terminated. 
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6.4 Generic Call Control Service State Transition Diagrams 



6.4.1 State Transition Diagrams for IpCallControlManager 

The state transition diagram shows the apphcation view on the Call Control Manager object. 



"a call object has terminated abnormally" "IpAppCallControlManager.callAborted 



dIsableCal INotifi cation 
enableCall Notlflcatio 




"arrival of call related event"[ notification active for this call event ] / 
create a Call object "IpAppCallControlManager.callEventNotIfy 

createCall / create a Call obj... 



Active 



Creation of 
CallControlManager 
by Service Instance 
LIfecycle Manager 



"notifications possible sk, 
"IpAppCallControl Managerial I Notiftcati 




"notifications not possible" 
Call Control Manager. cal INotifi catlonlnterrupted 



lpAccess.terniinateSen/ice Agreement 



4\ 



disableCal I Notification 
"a call object has terminated abnormally" 
"IpApp Cal I Control Managerial lAborted 

Notification terminated 



IpAccess.term 




nateSeivlceAgreem ent 



Figure : Application view on the Call Control Manager 



6.4.1.1 Active State 

In this state a relation between the Application and the Generic Call Control Service has been established. The state 
allows the application to indicate that it is interested in call related events. In case such an event occurs, the Call Control 
Manager will create a Call object and inform the application by invoking the operation callEventNotifyO on the 
IpAppCallControlManager interface. The application can also indicate it is no longer interested in certain call related 
events by calling disableCallNotification(). 

6.4.1 .2 Notification terminated State 

When the Call Control Manager is in the Notification terminated state, events requested with enableCalINotification() 
will not be forwarded to the application. There can be multiple reasons for this: for instance it might be that the 
application receives more notifications from the network than defined in the Service Level Agreement. Another 
example is that the Service has detected it receives no notifications from the network due to e.g. a hnk failure. In this 
state no requests for new notifications will be accepted. 



6.4.2 State Transition Diagrams for IpCall 

The state transition diagram shows the application view on the Call object for 3GPP. 
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IpAppCallConirolManager.callEv entNotif y 

"disconnect from called party"[ monitor mode 
interrbo! ] 'VouteRes, getCallInf oRes, 
\superv iseC. 



setCal IChatgePbn 
setAdv iceOf Charge 
superv iseCallReq 




[ no reports requested ^flth get 



IS, superviseCallRes 



In state No Parties and Finished, a timer 
should prevent the object from occupuing 
resources. 

Upon expiry of this timer, callEnded() should 
be inv oked with a release cause of 1 02 
(Recovery on timer expiry). In case when no 
IpAppCall is available on which to invoke 
callEnded(), callAborted() shall be invoked 
on the IpAppCallControlManager as this is 
an abnormal termination 



Figure : Application view on the IpCall object for 3GPP 



6.4.2.1 Network Released State 

In tliis state ttie call has ended and the Gateway collects the possible call information requested with getCalllnfoReqO 
and / or superviseCallReq(). The information will be returned to the application by invoking the methods 
getCalllnfoResO and / or superviseCallRes() on the application. Also when a call was unsuccessful these methods are 
used. In case the application has not requested additional call related information immediately a transition is made to 
state Finished. 
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6.4.2.2 Finished State 

In this state the call has ended and no call related information is to be send to the application. The application can only 
release the call object. Calling the deassignCaU() operation has the same effect. Note that the application has to release 
the object itself as good OO practice requires that when an object was created on behalf of a certain entity, this entity is 
also responsible for destroying it when the object is no longer needed. 

6.4.2.3 Application Released State 

In this state the application has requested to release the Call object and the Gateway collects the possible call 
information requested with getCalllnfoReqO and / or superviseCallReq(). In case the application has not requested 
additional call related information the Call object is destroyed immediately. 

6.4.2.4 Active State 

In this state a call between two parties is being setup or present. Refer to the substates for more details. The application 
can request supervision of the call by calling superviseCallReq(). It is also allowed to send Advice of Charge 
information by calling setAdviceOfCharge() as well as to define the charging by invoking setCallChargePlan.. 

6.4.2.5 1 Party in Call State 

When the Call is in this state a calling party is present. The appUcation can now request that a connection to a called 

party be established by calling the method routeReq(). 

In this state the application can also request the gateway for a certain type of charging of the call by calhng 
setCallChargePlan(). The application can also request for charging related information by calling getCalUnfoReq(). The 
setCallChargePlanO and getCalllnfoReqO should be issued before requesting a connection to a called party by means of 

routeReqO. 

When the calling party abandons the call before the application has invoked the routeReqO operation, the gateway 
informs the appUcation by invoking callFaultDetected() and also the operation callEnded() will be invoked. When the 
calling party abandons the call after the application has invoked routeReqO but before the call has actually been 
established, the gateway informs the application by invoking callEnded(). 

When the called party answers the call, a transition will be made to the 2 Parties in Call state. In case the call can not be 
established because the appUcation supplied an invalid address or the connection to the called party was unsuccessful 
while the appUcation was monitoring for the latter in interrupt mode, the Call object wiU stay in this state 

In this state user interaction is possible unless there is an outstanding routing request. 

6.4.2.6 2 Parties in Call State 

A connection between two parties has been estabUshed. 

In case the caUing party disconnects, the gateway informs the application by invoking callEnded(). 
When the caUed party disconnects different situations apply: 

1. the appUcation is monitoring for this event in interrupt mode: a transition is made to the 1 Party in Call state, the 
application is informed with routeRes with indication that the called party has disconnected and all requested reports are 
sent to the application. The application now again has control of the call. 

2. the appUcation is monitoring for this event but not in interrupt mode. In this case a transition is made to the Network 
Released state and the gateway informs the application by invoking the operation routeRes() and callEnded(). 

3. the application is not monitoring for this event. In this case the application is informed by the gateway invoking the 
callEndedO operation and a transition is made to the Network Released state. 

In this state user interaction is possible, depending on the underlying network. 
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6.5 Generic Call Control Service Properties 
6.5.1 List of Service Properties 



The following table lists properties relevant for the GCC API. 



P_TRIGGERING_EVENT_TYPES 


INTEGER_SET 


Indicates the static event types supported by the SCS. Static events are the events by 
which applications are initiated. 


P_DYNAMIC_EVENT_TYPES 


INTEGER_SET 


Indicates the dynamic event types supported by the SCS. Dynamic events are the events 
the application can request for during the context of a call. 


P_ADDRESSPLAN 


INTEGER_SET 


Indicates the supported address plan (defined in TpAddressPIan.) e.g. 
{P_ADDRESS_PLAN_E164,P_ADDRESS_PLAN_IP}) 


P_UI_CALL_BASED 


BOOLEAN_SET 


Value = TRUE : User interaction can be performed on call level and a reference to a Call 

object can be used in the IpUIManager.createUICallO operation. 

Value = FiVLSE: No User interaction on call le\ el is supported. 


P_UI_AT_ALL_STAGES 


BOOLEAN_SET 


Value = TRUE: User Interaction can be performed at any stage during a call . 

Value = FALSE: User Interaction can be performed in case there is only one party in the 
call. 


P_MEDIA_TYPE 


rNTEGER_SET 


Specifies the media type used by the Service. Values are defined by data-type 
TpMediaType : P_AUDIO, P_VIDEO, P_DATA 



The previous table lists properties related to capabilities of the SCS itself. The following table lists properties that are 
used in the context of the Service Level Agreement, e.g. to restrict the access of applications to the capabiUties of the 
SCS. 



III! Prnnprtw 






P_TRIGGERING_ADDRESSES 


ADDRESS_RANGE_SET 


Indicates for which numbers the notification may be set. For terminating 
notifications it applies to the terminating number, for originating 
notifications it applies only to the originating number. 


P_NOTIFICATION_TYPES 


INTEGER_SET 


Indicates whether the application is allowed to set originating and/or 
terminating triggers in the ECN. Set is: 

P_ORIGINATING 

P_TERMINATING 


P.MONITOR.MODE 


INTEGER_SET 


Indicates whether the application is allowed to monitor in interrupt and/or 

notify mode. Set is: 

P_INTERRUPT 
P_NOTIFY 


P_NUMBERS_TO_BE_CHANGED 


INTEGER_SET 


Indicates which numbers the application is allowed to change or fill for 

legs in an incoming call. Allowed value set: 

{P_ORIGINAL_CALLED_PARTY_NUMBER, 

P_REDIRECT1NG_NUMBER, 

P_TARGET_NUMBER, 

P_CALLING_PARTY_NUMBER}. 


P_CHARGEPLAN_ALLOWED 


INTEGER_SET 


Indicates which charging is allowed in the setCallChargePlan indicator. 
Allowed values: 

{P_TRANSPARANT_CHARGING, 

P_CHARGE_PLAN) 


P_CHARGEPLAN_MAPPING 


INTEGER_INTEGER_MAP 


Indicates the mapping of chargeplans (we assume they can be indicated 
with integers) to a logical network chargeplan indicator. When the 
chargeplan supports indicates P_CFLARGE_PLAN then only chargeplans 
in this mapping are allowed. 



6.5.2 Service Property values for the CAMEL Service Environment. 

Implementations of the Generic Call Control API relying on the CSE of CAMEL phase 3 shall have the Service 
Properties outlined above set to the indicated values : 



ETSI 



3GPP TS 29.198-04 version 4.4.0 Release 4 57 ETSI TS 129 198-4 V4.4.0 (2002-06) 



P_OPERATION_SET = { 

"IpCallControlManager . enableCallNotif ication", 

"IpCallControlManager . disableCallNotif ication", 

"IpCallControlManager . changeCallNot if ication", 

"IpCallControlManager . getCriteria", 

"IpCallControlManager . setCallLoadControl", 

"IpCall . routeReq", 

"IpCall . release", 

"IpCall .deassignCall", 

"IpCall .getCalllnfoReq", 

"IpCall . setCallChargePlan", 

"IpCall . setAdviceOf Charge", 

"IpCall . superviseCallReq" 

} 

P_TRIGGERING_EVENT_TYPES = { 

P_EVENT_GCCS_ADDRESS_COLLECTED_EVENT, 

P_EVENT_GCCS_ADDRESS_ANALYSED_EVENT, 

P_EVENT_GCCS_CALLED_PARTY_BUS Y , 

P_EVENT_GCCS_CALLED_PARTY_UNREACHABLE, 

P_EVENT_GCCS_NO_ANSWER_FROM_CALLED_PARTY, 

P_EVENT_GCCS_ROUTE_SELECT_FAILURE 

} 

P_DYNAMIC_EVENT_TYPES = { 
P_CALL_REPORT_ANSWER, 
P_CALL_REPORT_BUS Y , 
P_CALL_REPORT_NO_ANSWER, 
P_CALL_REPORT_DI SCONNECT , 
P_CALL_REPORT_ROUTING_FAILURE, 
P_CALL_REPORT_NOT_REACHABLE 
} 

P_ADDRESS_PLAN = { 
P_ADDRESS_PLAN_E1 64 

} 

P_UI_CALL_BASED = { 

TRUE 

} 

P_UI_AT_ALL_STAGES = { 

FALSE 

} 

P_MEDIA_TYPE = { 

P_AUDIO 

} 
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6.6 Generic Call Control Data Definitions 

This clause provides the GCC data definitions necessary to support the API specification. 
The general format of a Data Definition specification is described below. 

• Data Type 

This shows the name of the data type. 

• Description 

This describes the data type. 

• Tabular Specification 

This specifies the data types and values of the data type. 

• Example 

If relevant, an example is shown to illustrate the data type. 

All data types referenced but not defined in this clause are either in the common call control data definitions clause of 
the present document (clause 8) or in the common data definitions which may be found in 3GPP TS 29.198-2. 

6.6.1 Generic Call Control Event Notification Data Definitions 
6.6.1.1 TpCallEventName 



Defines the names of event being notified. The following events are supported. The values may be combined by a 
logical 'OR' function when requesting the notifications. Additional events that can be requested / received during the 
call process are found in the TpCaUReportType data-type. 



Name ^^^^^^^^^V 


Value 




P_EVENT_NAME_UNDEFINED 





Undefined 


P_EVENT_GCCS_OFFHOOK_EVENT 


1 


GCCS - Offhook event 

This can be used for iiot-line features. In case this event is set 
in the TpCallEventCriteria, only the originating address(es) 
may be specified in the criteria. 


P_EVENT_GCCS_ADDRESS_COLLECTED_EVENT 


2 


GCCS - Address information collected 
The network has collected the information from the A-party, 
but not yet analysed the information. The number can stiU be 
incomplete. Applications might set notifications for this event 
when part of the number analysis needs to be done in the 
application (see also the getMoreDialledDigitsReq method on 
the call class). 


P_EVENT_GCCS_ADDRESS_ANALYSED_EVENT 


4 


GCCS - Address information is analysed 

The dialled number is a valid and complete number in the 

network. 


P_EVENT_GCCS_CALLED_PARTY_BUSY 


8 


GCCS - Called party is busy 


P_EVENT_GCCS_CALLED_PARTY_UNREACHABLE 


16 


GCCS - Called party is unreachable (e.g. the called party has 
a mobile telephone that is currently switched off). 


P_EVENT_GCCS_NO_ANSWER_FROM_CALLED_PARTY 


32 


GCCS - No answer from called party 


P_EVENT_GCCS_ROUTE_SELECT_FAILURE 


64 


GCCS - Failure in routing the call 


P_EVENT_GCCS_ANSWER_FROM_CALL_PARTY 


128 


GCCS - Party answered call. 
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6.6.1.2 TpCallNotificationType 



Defines the type of notification. Indicates whether it is related to the originating of the terminating user in the call. 



.Name 


Value 


JJeaci-iDlioix. 


P_ORIGINATING 





Indicates that the notification is related to the originating user in the call. 


P_TERMINATING 


1 


Indicates that the notification is related to the terminating user in the call. 



6.6.1.3 TpCallEventCriteria 



Defines the Sequence of Data Elements that specify the criteria for a event notification. 

Of the addresses only the Plan and the AddrString are used for the purpose of matching the notifications against the 
criteria. 



Sequence Element 
■l^ Name 


Sequence Element 
Type 




DestinationAddress 


TpAddressRange 


Defines the destination address or address range for which the notification is 
requested. 


OriginatingAddress 


TpAddressRange 


Defines the origination address or a address range for which the notification is 

requested. 


CallEventName 


TpCallEventName 


Name of the event(s) 


CallNotif icationType 


TpCallNotificationType 


Indicates whether it is related to the originating or the terminating user in the 

call. 


MonitorMode 


TpCallMonitorMode 


Defines the mode that the call is in following the notification. 
Monitor mode P_CALL_MONlTOR_MODE_DO_NOT_MONITOR is not a 
legal value here. 



6.6.1.4 TpCallEventlnfo 

Defines the Sequence of Data Elements that specify the information returned to the application in a Call event 



notification. 






DestinationAddress 


TpAddress 


OriginatingAddress 


TpAddress 


OriginalDestinationAddress 


TpAddress 


RedirectingAddress 


TpAddress 


CallAppInfo 


TpCallAppInf oSet 


CallEventName 


TpCallEventName 


CallNotif icationType 


TpCallNotificationType 


MonitorMode 


TpCallMonitorMode 



6.6.2 Generic Call Control Data Definitions 

6.6.2.1 IpCall 

Defines the address of an IpCall Interface. 

6.6.2.2 IpCallRef 

Defines a Reference to type IpCall. 
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6.6.2.3 IpAppCall 

Defines the address of an IpAppCall Interface. 

6.6.2.4 IpAppCallRef 

Defines a Reference to type IpAppCall 

6.6.2.5 TpCallldentifier 



Defines the Sequence of Data Element s that unambiguously specify the Generic Call object 



Sequence Element 
toi^^ Name 


Sequence Element 


Sequence Element Description 


CallRef erence 


IpCallRef 


Tliis element specifies tlie interface reference for the call object. 


CallSessionID 


TpSessionID 


This element specifies the call session ID of the call. 



6.6.2.6 IpAppCallControlManager 

Defines the address of an IpAppCallControlManager Interface. 

6.6.2.7 IpAppCallControlManagerRef 

Defines a Reference to type IpAppCallControlManager. 

6.6.2.8 IpCallControlManager 

Defines the address of an IpCallControlManager Interface. 

6.6.2.9 IpCallControlManagerRef 

Defines a Reference to type IpCallControlManager. 

6.6.2.10 TpCallApplnfo 



Defines the Tagged Choice of Data Elements that specify application-related call information. 





Tag Element Type 






'i'p C a 1 1; ipp 1 n f c Typ e 





Tag Element 


Choice Element 


Choice Element Name 


ValuelHHBHHA 




P_CALL_APP_ALERT ING_MECHANI SM 


TpCallAlertingMechanism 


CallAppAlertingMechanism 


P_CALL_APP_NETWORK_ACCESS_TYPE 


TpCallNetworkAccessType 


CallAppNetworkAccessType 


P_CALL_APP_TELE_SERVICE 


TpCallTeleService 


CallAppTele Service 


P_CALL_APP_BEARER_SERVICE 


TpCallBearerService 


CallAppBearer Service 


P_C i iL L_. i P P _t' . U< ^' i _C . i ^ E G K i 


TpCallzarryCaregcry 


C a i i /ip p Party C a t e g o r y 


P_C AL L_AP P_PRESENTATI ON_ADDRE S S 


TpAddress 


CallAppPresentat ionAddress 


P_CALL_APP_GENERIC_INFO 


TpString 


CallAppGenericInf o 


P_C AL L_AP P_ADD I T I ONAL_ADDRE S S 


TpAddress 


CallAppAdditionalAddress 
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6.6.2.11 TpCallApplnfoType 



Defines the type of call application-related specific information. 





Value 


Description 


P_CALL_APP_UNDEFINED 





Undefined 


P_CALL_APP_ALERTING_MECHANISM 


1 


The alerting meclianism or pattern to use 


P_CALL_APP_NETWORK_ACCESS_TYPE 


2 


The network access type (e.g. ISDN) 


P_CALL_APP_TELE_SERVICE 


3 


Indicates the tele-service (e.g. telephony) 


P_CALL_APP_BEARER_SERVICE 


4 


Indicates the bearer service (e.g. 64kbit/s unrestricted data). 


P_CALL_APP_PARTY_CATEGORY 


5 


The category of the calling party 


P_CyiLL_yiP P_P 1< E SLA J ^ OA_yi J Jl^L S S 




The address to be presented to other call parties 


P_CALL_APP_GENERIC_INFO 


7 


Carries unspecified service-service information 


P_C AL L_AP P_AD D I T I ONAL_AD D RE S S 


8 


Indicates an additional address 



6.6.2.12 TpCallApplnfoSet 

Defines a Numbered Set of Data Elements of TpCallAppInfo. 



6.6.2.13 TpCallEndedReport 

Defines the Sequence of Data Elements that specify the reason for the call ending. 



Sequence E lement 

CallLegSessionID 



Sequence El eme nt 

TpSessionID 



The leg that initiated the release of the call. 
If the call release was not initiated by the leg, then this value is set to -1 . 



Cause 



TpCallReleaseCause 



The cause of the caU ending. 



6.6.2.14 TpCallFault 

Defines the cause of the call fault detected. 



P_CALL_FAULT_UNDEFINED 





Undefined 


P_CALL_TIMEOUT_ON_RELEASE 


I 


This fault occurs when the final report has 
been sent to the application, but the application 
did not expUcitly release or deassign the call 
object, within a specified time. 

The timer value is operator specific. 


P_CALL_TIMEOUT_ON_INTERRUPT 


2 


This fault occurs when the application did not 
instruct the gateway how to handle the call 
within a specified time, after the gateway 
reported an event that was requested by the 
application in interrupt mode. 

The timer value is operator specific. 
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6.6.2.15 TpCalllnfoReport 

Defines the Sequence of Data Elements that specify the call information requested. Information that was not 
requested is invalid. 



Sequence Elen^^^^V^ 
■■■■■■^.Name^^^^^^^^lll 


Sequence Element 


Description 


Callinf oType 


TpCallInf oType 


The type of call report. 


Call InitiationSt art Time 


TpDateAndTime 


The time and date when the call, or follow-on call, was 
started as a result of a routeReq. 


CallConnectedToResourceTime 


TpDateAndTime 


The date and time when the call was cormected to the 

resource. 

This data element is only valid when information on user 
interaction is reported. 


CallConnectedToDestinationTime 


TpDateAndTime 


The date and time when the call was connected to the 
destination (i.e. when the destination answered the call). 
If the destination did not answer, the time is set to an 
empty string. 

This data element is invalid when information on user 
interaction is reported. 


CallEndTime 


TpDateAndTime 


The date and time when the call or follow-on call or user 
interaction was terminated. 


Cause 


TpCallReleaseCause 


The cause of the termination. 



A calUnfoReport will be generated at the end of user interaction and at the end of the connection with the associated 
address. This means that either the destination related information is present or the resource related information, but not 
both. 



6.6.2.16 TpCallReleaseCause 



Defines the Sequence of Data Elements that specify the cause of the release of a call. 







Value 


Tplnt32 


Location 


Tplnt32 


NOTE: The Value and Location are specified as in ITU-T Recommendation Q.850. 



The following example was taken from Q.850 to aid imderstanding: 





Cause Value Set by 


Cause Value from 


P_CALL_REPORT_BUSY 


17 


17 


P_CALL_REPORT_NO_ANSWER 


19 


18,19,21 


P_CALL_REPORT_DISCONNECT 


16 


16 


P_CALL_REPORT_REDIRECTED 


23 


23 


P_CALL_REPORT_SERVICE_CODE 


31 


NA 


P_CALL_REPORT_NOT_REACHABLE 


20 


20 


P_CALL_REPORT_ROUTING_FAILURE 


3 


Any other value 
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6.6.2.17 TpCallReport 



Defines the Sequence of Data Elements that specify the call report and call leg report specific information. 



^^^^^^^^^^ Sequence Elemen^^^^^^^^^^^ 


^^^^^^^ Sequence Element ^^^^^J 


HHHIIIB Name n^^^^^^^^^H 


HHHIk Type ^HIH 


MonitorMode 


TpCallMonitorMode 


CallEventTime 


TpDateAndTime 


CallReportType 


TpCallReport Type 


AdditionalReport Inf o 


TpCallAdditionalReportInf o 



6.6.2.18 TpCallAdditionalReportlnfo 

Defines the Tagged Choice of Data Elements that specify additional call report information for certain types 
of reports. 





Taq Element Type 






TpCallReport Type 









Choice Element Name 


P_C AL L_RE P ORT_UND E F I NE D 


NULL 


Undefined 


P_C AL L_RE P ORT_P ROGRE S S 


NULL 


Undefined 


P_CALL_REPORT_ALERTING 


NULL 


Undefined 


P_CALL_REPORT_ANSWER 


NULL 


Undefined 


P_CALL_REPORT_BUSY 


TpCaUReleaseCause 


Busy 


P_CALL_REPORT_NO_ANSWER 


NULL 


Undefined 


P_CALL_REPORT_DISCONNECT 


TpCaUReleaseCause 


CaUDisconnect 


P_CALL_REPORT_REDIRECTED 


TpAddress 


ForwardAddress 


P_CALL_REt'ORJ_SERViCE_COJE 


TpCallScrviccCodc 


ScrviccCodc 


P_CALL_REP ORT_ROUT ING_FAI LURE 


TpCaUReleaseCause 


RoutingFailure 


P_CALL_REPORT_QUEUED 


TpString 


Queues tatus 


P_CALL_REPORT_NOT_REACHABLE 


TpCaUReleaseCause 


NotReachable 



6.6.2.19 TpCallReportRequest 



Defines the Sequence of Data Elements that specify the criteria relating to caU report requests. 



^^^^^^^^^Bequence Element M^^^^^^^^^^H 




MonitorMode 


TpCallMonitorMode 


CallReportType 


TpCallReportType 


AdditionalReport Criteria 


TpCallAdditionalReportCriteria 
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6.6.2.20 TpCallAdditionalReportCriteria 



Defines the Tagged Choice of Data Elements that specify specific criteria. 





Iafl.itement Type 






TpCallReportType 





Tag Element ^^^^^^■■^^^MMphoice Element 


Choice Element 


P_CALL_REPORT_UNDEFINED 


NULL 


Undefined 


P_C AL L_RE P ORT_P RO GRE S S 


NULL 


Undefined 


P_CALL_REPORT_ALERTING 


NULL 


Undefined 


P„CALL_REPORT_ANSWER 


NULL 


Undefined 


P_CALL_REPORT_BUSY 


NULL 


Undefined 


P_CALL_REPORT_NO_ANSWER 


TpDuration 


NoAnswerDuration 


P_CALL_REPORT_D I SCONNECT 


NULL 


Undefined 


P_CALL_REPORT_REDIRECTED 


NULL 


Undefined 


P_CALL_REPORT_SERVICE_CODE 


TpCallServiceCode 


ServiceCode 


P_CALL_REPORT_ROUTING_FAILURE 


NULL 


Undefined 


P_CALL_REP ORT_QUEUED 


NULL 


Undefined 


P_C J iL L_l< L P 01< _ _ _KL J 1 _j iP L L 


NULL 


Undefined 



6.6.2.21 TpCallReportRequestSet 

Defines a Numbered Set of Data Elements of TpCallReportRequest. 

6.6.2.22 TpCallReportType 



Defines a specific call event report type. 









P_CALL_REPORT_UNDEFINED 





Undefined. 


P_C ALL_REP ORT_P ROGRE S S 


1 


Call routing progress event: an indication from the network that progress has been made in 
routing the caU to the requested call party. This message may be sent more than once, or 
may not be sent at all by the gateway with respect to routing a given caU leg to a given 

address. 


P_CALL_REP ORT_ALERT ING 


2 


Call is alerting at the call party. 


P_CALL_REPORT_ANSWER 


3 


CaU answered at address. 


P_CALL_REPORT_BUSY 


4 


Called address refused call due to busy. 


P_CALL_REPORT_NO_ANSWER 


5 


No answer at called address. 


P_CALL_REPORT_DI SCONNECT 


6 


The media stream of the called party has disconnected. This does not imply that the call has 
ended. When the call is ended, the callEnded method is called. This event can occur both 
when the called party hangs up, or when the application exphcitly releases the leg using 
IpCaULeg.releaseO This carmot occur when the app explicitly releases the call leg and the 

call. 


P_CALL_REPORT_REDIRECTED 


7 


Call redirected to new address: an indication from the network that the call has been 
redirected to a new address. 


P_CALL_REPORT_SERVICE_CODE 


8 


Mid-call service code received. 


P_CALL_REPORT_ROUT ING_FAI LURE 


9 


Call routing failed - re-routing is possible. 


P_CALL_REPORT_QUEUED 


10 


The call is being held in a queue. This event may be sent more than once during the routing 

of a call. 


P_C AL L_RE P ORT_NO T_RE ACH AB LE 


11 


The called address is not reachable; e.g., the phone has been switched off or the phone is 
outside the coverage area of the network. 
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6.6.2.23 TpCallTreatment 

Defines the Sequence of Data Elements that specify the treatment for calls that wiU be handled only by the 
network (for example, call which are not admitted by the call load control mechanism). 



Sequence Element 


Sequence Elem^^^^^V 


CallTreatmentType 


TpCallTreatment Type 


ReleaseCause 


TpCallReleaseCause 


AdditionalTreatment Inf o 


TpCallAdditionalTreatmentInf o 



6.6.2.24 TpCallEventCriteriaResultSet 

Defines a set of TpCallEventCriteriaResult. 

6.6.2.25 TpCallEventCriteriaResult 



Defines a sequence of data elements that specify a requested call event notification criteria with the associated 
assignmentlD. 







^^^^^^^^^^^^^^^^Saguence Element ^^^^^^^^^^^^J 
^^^^^^^^^^^^^^^^^^Hkcription 


1 Event Criteria 


TpCallEventCriteria 


The event criteria that were specified by the application! 


1 AssignmentlD 


Tplnt32 


The associated assignmentlD. This can be used to disable the notification. | 



7 MultiParty Call Control Service 

The Multi-Party Call Control API of 3GPP Rel4 rehes on the CAMEL Service Environment (CSE). It should be noted 
that a number of restrictions exist because CAMEL phase 3 supports only two-party calls and no leg based operations. 
Furthermore application initiated calls are not supported in CAMEL phase 3. The detailed description of the supported 
methods is given in the chapter 7.5. 

7.1 Sequence Diagrams 

7.1 .1 Application initiated call setup 

The following sequence diagram shows an application creating a call between party A and party B. Here, a call is 
created first. Then party A's call leg is created before events are requested on it for answer and then routed to the call. 
On answer from Party A, an announcement is played indicating that the call is being set up to party B. While the 
announcement is being played, party B's call leg is created and then events are requested on it for answer. On answer 
from Party B the announcement is cancelled and party B is routed to the call. 

The service may as a variation be extended to include 3 parties (or more). After the two party call is established, the 
application can create a new leg and request to route it to a new destination address in order to establish a 3 party call. 

The event that causes this to happen could for example be the report of answer event from B-party or controlled by the 
A-party by entering a service code (mid-call event). 

The procedure for call setup to party C is exactly the same as for the set up of the connection to party B (sequence 13 to 
17 in the sequence diagram). 
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IpAppMultiPartyCall 


AooPartvA : 
(IpAppMultiPartyCallLeq) 


ADPPartvB : 
[IpAppMultiPartvCallLeql 


IpApoUICall 



13: crealeCflllLeg( ) 



15. ei/enlRepoilReq( 



r 









PartvA : 


PartvB : 




:lDUICall 


IpMultiPartyCallControl Manager 




IpMultiPartvCall 


IpCallLeq 


IpCallLeq 


IpUIManaqer 





9: EventReportHes () 



r 



abort ActronReq( ) 



1: This message is used to create an object implementing the IpAppMuhiP arty Call interface. 

2: This message requests the object implementing the IpMultiPartyCallControlManager interface to create an object 
implementing the IpMultiPartyCall interface. 

3: Assuming that the criteria for creating an object implementing the IpMultiPartyCall interface (e.g. load control 
values not exceeded) is met it is created. 

4: Once the object implementing the IpMultiPartyCall interface is created it is used to pass the reference of the object 
implementing the IpAppMultiPartyCall interface as the callback reference to the object implementing the 
IpMultiPartyCall interface. Note that the reference to the callback interface could already have been passed in the 
createCall. 

5: This message instructs the object implementing the IpMultiPartyCall interface to create a call leg for customer A. 

6: Assuming that the criteria for creating an object implementing the IpCallLeg interface is met, message 6 is used to 
create it. 

7: This message requests the call leg for customer A to inform the application when the call leg answers the call. 
8: The call is then routed to the originating call leg. 

9: Assuming the call is answered, the object implementing party A's IpCallLeg interface passes the result of the call 
being answered back to its callback object. This message is then forwarded via another message (not shown) to the 
object implementing the IpAppLogic interface. 

10: A UlCall object is created and associated with the just created call leg. 

11: This message is used to inform party A that the call is being routed to party B. 

12: An indication that the dialogue with party A has commenced is returned via message 13 and eventually forwarded 
via another message (not shown) to the object implementing the IpAppLogic interface. 
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13: This message instructs the object implementing the IpMultiPartyCall interface to create a call leg for customer B. 
14: Assuming that the criteria for creating a second object implementing the IpCallLeg interface is met, it is created. 
15: This message requests the call leg for customer B to inform the application when the call leg answers the call. 
16: The call is then routed to the call leg. 

17: Assuming the call is answered, the object implementing party B's IpCallLeg interface passes the result of the call 
being answered back to its callback object. This message is then forwarded via another message (not shown) to the 
object implementing the IpAppLogic interface. 

18: This message then instructs the object implementing the IpUICall interface to stop sending announcements to party 
A. 

19: The application deassigns the call. This will also deassign the associated user interaction. 



7.1.2 Call Barring 2 

The following sequence diagram shows a call barring service, initiated as a result of a prearranged event being received 
by the framework. Before the call is routed to the destination number, the calling party is asked for a PIN code. The 
code is rejected and the call is cleared. 



IpAppMuIti Part vCallControl Manager IpAppMu 
1 ; new(] 



4: 'forward event' 



2: cresteNotif icationi 



PartyCall IpAppUICall 



: iDMultiPartvCallConlrolManaaer 


IpMultiPartyCall 





reportNotifcation( ] 



10: 'forward event' 



13: 'forward event' 



7: createUIC^II( ) 



8: EendlnfiAndCollectReq( ] 



1: sydinf oReq( ) 



14: release( ) 



9: sendinf oAndCollectRes ) 



12; EendlnfoRes( ] 



1: This message is used by the application to create an object implementing the IpAppMultiPartyCallControlManager 
interface. 

2: This message is sent by the application to enable notifications on new call events. As this sequence diagram depicts 
a call barring service, it is likely that all new call events destined for a particular address or address range prompted for 



ETSI 



3GPP TS 29.198-04 version 4.4.0 Release 4 



68 



ETSI TS 129 198-4 V4.4.0 (2002-06) 



a password before the call is allowed to progress. When a new call, that matches the event criteria, arrives a message 
(not shown) is directed to the object implementing the IpMultiPartyCallControlManager. Assuming that the criteria for 
creating an object implementing the IpMultiPartyCall interface (e.g. load control values not exceeded) is met, other 
messages (not shown) are used to create the call and associated call leg object. 

3: This message is used to pass the new call event to the object implementing the 
IpAppMultiPartyCallControlManager interface. 

4: This message is used to forward message 3 to the IpAppLogic. 

5: This message is used by the application to create an object implementing the IpAppMultiPartyCall interface. The 
reference to this object is passed back to the object implementing the IpMultiPartyCallControlManager using the retiu'n 
parameter of the callEventNotify. 

6: The application requests an list of all the legs currently in the call. 

7: This message is used to create a UlCall object that is associated with the incoming leg of the call. 
8: The call barring service dialogue is invoked. 

9: The result of the dialogue, which in this case is the PIN code, is returned to its callback object. 
10: This message is used to forward the previous message to the IpAppLogic 

1 1 : Assuming an incorrect PIN is entered, the calling party is informed using additional dialogue of the reason why the 
call cannot be completed. 

12: This message passes the indication that the additional dialogue has been sent. 
13: This message is used to forward the previous message to the IpAppLogic. 
14: No more UI is required, so the UlCall object is released. 
15: This message is used by the application to clear the call. 



7.1 .3 Call forwarding on Busy Service 

The following sequence diagram shows an appUcation establishing a call forwarding on busy. 

When a call is made from A to B but the B-party is detected to be busy, then the application is informed of this and sets 
up a connection towards a C party. The C party can for instance be a voicemail system. 
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: reportNotification( ) 



16;createCallLeg( ) 



20;routeReq( ) 



23;continuePrCjCess[ng( ) 



state>ra nsition to Releasii 



2fl;"intormCall 



25; "continue call processing' 



27:eventReportRes( ) 



18: "stae transition to Idle" 



21:"stafe lransitiontoActi\(^" 



1: This message is used by the application to create an object implementing the IpAppMultiPartyCallControlManager 
interface. 

2: This message is sent by the application to enable notifications on new call events. 

4: When a new call, that matches the event criteria, arrives a message ("busy") is directed to the object implementing 
the IpMultiPartyCallControlManager. Assuming that the criteria for creating an object implementing the 
IpMultiP arty Call interface is met, other messages are used to create the call and associated call leg objects. 

6: A new MultiPartyCaU object is created to handle this particular call. 

7: A new CallLeg object corresponding to Party A is created. 

8: The new Call Leg instance transits to state Initiating. 

1 1: This message is used to pass the new call event to the object implementing the 
IpAppMultiPartyCallControlManager interface. Applied monitor mode is "interrupt" 

12: This message is used to forward the message to the IpAppLogic. 

13: This message is used by the application to create an object implementing the IpAppMultiPartyCall interface. The 
reference to this object is passed back to the object implementing the IpMultiPartyCallControlManager using the return 
parameter of the reportNotification. 

14: A new AppCallLeg is created to receive callbacks for the Leg corresponding to party A. 
15: A new AppCallLeg C is created to receive callbacks for another leg. 

16: This message is used to create a new call leg object. The object is created in the idle state and not yet routed in the 
network. 
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19: The application requests to be notified (monitor mode "INTERRUPT") when party C answers the call. 

20: The apphcation requests to route the terminating leg to reach the associated party C. 

The application may request information about the original destination address be sent by setting up the field 
P_CALL_APP_ORIGINAL_DESTINATION_ADDRESS of TpCaUAppInfo in the request to route the caU leg to the 
remote party C. 

23: The application requests to resume call processing for the terminating call leg to party B to terminate the leg. 
Alternative the apphcation could request to deassign the leg to party B for example if it is not interested in possible 
requested call leg information (getlnfoRes, superviseRes). 

When the terminating call leg is destroyed, the AppLeg B is notified and the event is forwarded to the application logic 
(not shown). 

25: The application requests to resume call processing for the originating call leg. 

As a result call processing is resumed in the network that will try to reach the associated party B. 

26: When the party C answers the call, the termination call leg is notified. 

27: Assuming the call is answered, the object implementing party C's IpCallLeg interface passes the result of the call 
being answered back to its callback object. 

28: This answer message is then forwarded to the object implementing the IpAppLogic interface. 



7.1 .4 Call Information Collect Service 

The following sequence diagram shows an application monitoring a call between party A and a party B in order to 
collect call information at the end of the call for e.g. charging and/or statistic information collection piuposes. The 
service may apply to ordinary two-party calls, but could also include a number translation of the dialled number and 
special charging (e.g. a premium rate service) . 

Additional call leg related information is requested with the getlnfoReq and superviseReq methods. 

The answer and call release events are in this service example requested to be reported in notify mode and 

additional call leg related information is requested with the getlnfoReq and superviseReq methods in order to illustrate 
the information that can be collected and sent to the application at the end of the call. 

Furthermore is shows the order in which information is sent to the application: network release event followed by 
possible requested call leg information, then the destroy of the call leg object (callLegEnded) and finally the destroy of 
the call object (callEnded). 
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1^ gethfcReq( ) 



3: ^etChargePlan( ) 



2i: rcufeReq( ) 



1: eventRepor|Req( ) 



25:get!nbReq( j 



26: continueProcpssing( ) 



30: eventReportRes( ] 



34:eventReportRes( ) 



36: getlnfoRes( ) 



38: callLegEnd6d( ) 



43: eventReportRes( ) 



45;gellnfoRes( ) 



47: superviseRes( ) 



3: "st^r 



8: "statWransition to Actiw 



16; "sn 
> 



! transition to Idle" 



22; "stalkllransition to Acti\fi" 



27: "inform Call objet 

28J^'t|ontinuecal I processing" 



p9; "B party ar 



32; "Disconne;t from A-party 



33; "statewansition to Releasing" 



4|); "inform Call ot)je:t 

^ n 



41; "pisconnect from B 



ttinsiti 



42: "state transition to 



1: This message is used by the application to create an object implementing the IpAppMultiPartyCallControlManager 
interface. 

2; This message is sent by the application to enable notifications on new call events. 
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4: When a new call, that matches the event criteria, arrives a message ("analysed information") is directed to the object 
implementing the IpMultiPartyCallControlManager. Assuming that the criteria for creating an object implementing the 
IpMultiPartyCall interface is met, other messages are used to create the call and associated call leg object 

6: A new MultiPartyCaU object is created to handle this particular call. 

7: A new CallLeg object corresponding to Party A is created. 

8: The new Call Leg instance transits to state Active. 

9: This message is used to pass the new call event to the object implementing the 
IpAppMultiPartyCallControlManager interface. Applied monitor mode is "interrupt" 

10: This message is used to forward message 9 to the IpAppLogic. 

1 1: This message is used by the appUcation to create an object implementing the IpAppMultiPartyCall interface. The 
reference to this object is passed back to the object implementing the IpMultiPartyCallControlManager using the return 
parameter of the reportNotification. 

12: A new AppCallLeg is created to receive callbacks for the Leg corresponding to party A. 
13: A new AppCallLeg is created to receive callbacks for another leg. 

14: This message is used to create a new call leg object. The object is created in the idle state and not yet routed in the 
network. 

15: A new CallLeg corresponding to party B is created. 

16: A transition to state Idle is made after the Call leg has been created. 

17: The appUcation requests to be notified (monitor mode "NOTIFY") when party B answers the call and when the leg 
to B-party is released. 

18: The application requests to supervise the call leg to party B. 

19: The application requests information associated with the call leg to party b for example to calculate charging. 
20: The application requests a specific charge plan to be set for the call leg to party B. 
21: The application requests to route the terminating leg to reach the associated party B. 
22: The Call Leg instance transits to state Active. 

24: The application requests to be notified (monitor mode "Notify") when the leg to A-party is released. 

25: The application requests information associated with the call leg to party A for example to calculate charging. 

26: The application requests to resume call processing for the originating call leg. 

As a result call processing is resumed in the network that will try to reach the associated party B. 

29: When the B-party answers the call, the termination call leg is notified. 

30: Assuming the call is answered, the object implementing party B's IpCallLeg interface passes the result of the call 
being answered back to its callback object (monitor mode "NOTIFY"). 

3 1 : This answer message is then forwarded. 

32: When the A-party releases the call, the originating call leg is notified (monitor mode "NOTIFY") and makes a 
transition to "releasing state". 

34: The application IpAppLeg A is notified, as the release event has been requested to be reported in Notify mode. 

35: The event is forwarded to the application logic 

36: The call leg information is reported. 

37: The event is forwarded to the appUcation logic 
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38: The origination call leg is destroyed, the AppLeg A is notified. 
39: The event is forwarded to the appUcation logic 

41: When the B-party releases the call or the call is released as a result of the release request from party A, i.e. a 
"originating release" indication, the terminating call leg is notified and makes a transition to "releasing state". 

43: If a network release event is received being a "terminating release" indication from called party B, the application 
IpAppLeg B is notified, as the release event from party B has been requested to be reported in NOTIFY mode. 

Note that no report is sent if the release is caused by propagation of network release event being a "originating release" 
indication coming from calling party A. 

44: The event is forwarded to the application logic. 

45: The call leg information is reported. 

46: The event is forwarded to the application logic. 

47: The supervised call leg information is reported. 

48: The event is forwarded to the application logic. 

49: The terminating call leg is destroyed, the AppLeg B is notified. 

50: The event is forwarded to the application logic. 

52: Assuming the IpCall object has been informed that the legs have been destroyed, the IpAppMultiPartyCall is 
notified that the call is ended . 

53: The event is forwarded to the application logic. 



7.1 .5 Complex Card Service 

The following sequence diagram shows an advanced card service, initiated as a result of a prearranged event being 
received by the framework. Before the call is made, the calling party is asked for an ID and PIN code. If the ID and PIN 
code are accepted, the calling party is prompted to enter the address of the destination party. A trigger of '#5' is then set 
on the controlling leg (the calling party's leg) such that if the calling party enters a '#5' an event will be sent to the 
apphcation. The call is then routed to the destination party. Sometime during the call the calhng party enters '#5' which 
causes the called leg to be released. The calhng party is now prompted to enter the address of a new destination party, to 
which it is then routed. 
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1: This message is used by the application to create an object implementing the IpAppMultiPartyCallControlManager 
interface. 

2: This message is sent by the application to enable notifications on new call events. As this sequence diagram depicts 
a call barring service, it is likely that all new call events destined for a particular address or address range result in the 
caller being prompted for a password before the call is allowed to progress. When a new call, that matches the event 
criteria set in message 2, arrives a message (not shown) is directed to the object implementing the 
IpMultiPartyCallControlManager. Assuming that the criteria for creating an object implementing the IpMultiPartyCall 
interface (e.g. load control values not exceeded) is met, other messages (not shown) are used to create the call and 
associated call leg object. 

3: This message is used to pass the new call event to the object implementing the 
IpAppMultiPartyCallControlManager interface. 
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4: This message is used to forward message 3 to the IpAppLogic. 

5: This message is used by the application to create an object implementing the IpAppMultiPartyCall interface. The 
reference to this object is passed back to the object implementing the IpMultiPartyCallControlManager using the return 
parameter of message 3. 

6: This message returns the call legs currently in the call. In principle a reference to the call leg of the calhng party is 
already obtained by the application when it was notified of the new call event. 

7: This message is used to associate a user interaction object with the calling party. 

8: The initial card service dialogue is invoked using this message. 

9: The result of the dialogue, which in this case is the ID and PIN code, is returned to its callback object using this 
message and eventually forwarded via another message (not shown) to the IpAppLogic. 

10: Assuming the correct ID and PIN are entered, the final dialogue is invoked. 

1 1 : The result of the dialogue, which in this case is the destination address, is returned and eventually forwarded via 
another message (not shown) to the IpAppLogic. 

12: This message is used to forward the address of the callback object. 

13: The trigger for follow-on calls is set (on service code). 

14: A new AppCallLeg is created to receive callbacks for another leg. Alternatively, the already existing AppCallLeg 
object could be passed in the subsequent createCallLeg(). In that case the application has to use the sessionlDs of the 
legs to distinguish between callbacks destined for the A-leg and callbacks destined for the B-leg. 

15: This message is used to create a new call leg object. The object is created in the idle state and not yet routed in the 
network. 

16: The application requests to be notified when the leg is answered. 

17: The application routes the leg. As a result the network will try to reach the associated party. 
18: When the B-party answers the call, the appUcation is notified. 
19: The event is forwarded to the application logic. 

20: Legs that are created and routed explicitly are by default in state detached. This means that the media is not 
connected to the other parties in the call. In order to allow inband communication between the new party and the other 

parties in the call the media have to be explicitly attached. 

21: At some time during the call the calhng party enters '#5'. This causes this message to be sent to the object 
implementing the Ip AppCallLeg interface, which forwards this event as a message (not shown) to the IpAppLogic. 

22: The event is forwarded to the application. 

23: This message releases the called party. 

24: Another user interaction dialogue is invoked. 

25: The result of the dialogue, which in this case is the new destination address is returned and eventually forwarded via 
another message (not shown) to the IpAppLogic. 

26: A new AppCallLeg is created to receive callbacks for another leg. 

27: The call is then forward routed to the new destination party. 

28: As a result a new CalUeg object is created. 

29: This message passes the result of the call being answered to its callback object and is eventually forwarded via 
another message (not shown) to the IpAppLogic. 

30: When the A-party ternoinates the application is informed. 
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31: The event is forwarded to the application logic. 

32: Since the release of the A-party will in this case terminate the entire call, the application is also notified with this 

message. 

33: The event is forwarded to the application logic. 

34: Since the user interaction object were not released at the moment that the call terminated, the application receives 
this message to indicate that the Ul resources are released in the gateway and no further communication is possible. 

35: The event is forwarded to the application logic. 

36: The application deassigns the call object. 



The following sequence diagram shows an application establishing a call between party A and pre-arranged party B 
defined to constitute a hot-line address. The address of the destination party is provided by the application as the calling 
party makes a call attempt (goes off-hook) and do not dial any number within a predefined time. In this case a pre- 
defined number (hot-line number) is provided by the apphcation. The call is then routed to the pre-defined destination 



The call release is monitored to enable the sending of information to the application at call release, e.g. for charging 
purposes. 

Note that this service could be extended as follows: 

Sometime during the call the calling party enters '#5' which causes the called leg to be released. The calling party is now 
prompted to enter the address of a new destination party, to which it is then routed. 



7.1.6 



Hotline Service 



party. 
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r 

' 32:' 



2: c(eateNo1ifcatiai( ) 



3: "armtiiggef" 



4: "trigge event: Origitialing Call Attempt Authorised" 



5: "c heck [fjppli cation interested" 



9: repQrtNotificatlon( ) 



17:k^entReportReq( ) 



21: e\en1RepohReq( ) 



29:e/entReportRes( ) 



31:cailLegEn(fed( ) 



36:cailLegEnded( ) 



:: " stale yansiti on to Initiating' 



16: "siajetransitii 



20: "inform dall otiject" 



|23: "intorm Call objei 



'aintinuecali processilig" 



25: e^Je^t "addressanalysed" 



26: "staid transition to Acti*", 



27: 'I'Disconnect from B-p^rtv'' 
28: " state Itr^siti on to Reieasi 



33: "inform dall object" 



34: "Disconnett from A-party" 



35: "state tfansition to Releasing" 



: "inform Call object 



1: This message is used by the application to create an object implementing the IpAppMultiPartyCallControlManager 
interface. 

2: This message is sent by the application to enable notifications on new call events. 

4: When a new call, that matches the event criteria, arrives a message ("analysed information") is directed to the object 
implementing the IpMultiPartyCallControlManager. Assuming that the criteria for creating an object implementing the 
IpMultiP arty Call interface is met, other messages are used to create the call and associated call leg object 

6: A new MultiPartyCall object is created to handle this particular call. 

7: A new CallLeg object corresponding to Party A is created. 
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8: The new Call Leg instance transits to state Initiating. 

9: This message is used to pass the new call event to the object implementing the 
IpAppMultiPartyCallControlManager interface. Applied monitor mode is "interrupt" 

10: This message is used to forward message 9 to the IpAppLogic. 

1 1: This message is used by the application to create an object implementing the IpAppMultiPartyCall interface. The 
reference to this object is passed back to the object implementing the IpMultiPartyCallControlManager using the return 
parameter of the reportNotification. 

12: A new AppCallLeg is created to receive callbacks for the Leg corresponding to party A. 
13: A new AppCallLeg is created to receive callbacks for another leg. 

14: This message is used to create a new call leg object. The object is created in the idle state and not yet routed in the 
network. 

15: A new CallLeg corresponding to party B is created. 

16: A transition to state Idle is made after the Call leg has been created. 

17: The application requests to be notified (monitor mode "NOTIFY") when the leg to party B is released. 

18: The application requests to route the terminating leg to reach the associated party as specified by the application 
("hot-line number"). 

19: The Call Leg instance transits to state Active. 

21: The application requests to be notified (monitor mode "Notify") when the leg to A-party is released. 
22: The application requests to resume call processing for the originating call leg. 

As a result call processing is resumed in the network that will try to reach the associated party as specified by the 
application (E. 164 number provided by application). 

25: The originating call leg is notified that the number (provided by application) has been analysed by the network and 
the originating call leg STD makes a transition to "active" state. The application is not notified as it has not requested 
this event to be reported. 

27: When the B-party releases the call, the terminating call leg is notified (monitor mode "NOTIFY") and makes a 
transition to "Releasing state". 

29: The application is notified, as the release event has been requested to be reported in Notify mode. 

30: The event is forwarded to the application logic. 

31: The terminating call leg is destroyed, the AppLeg B is notified. 

32: This answer message is then forwarded. 

34: When the call release ("terminating release" indication) is propagated in the network toward the party A, the 
originating call leg is notified and makes a transition to "releasing state". This release event (being propagated from 
party B) is not reported to the appUcation. 

36: When the originating call leg is destroyed, the AppLeg A is notified. 
37: The event is forwarded to the appUcation logic 

39: When all legs have been destroyed, the IpAppMultiPartyCall is notified that the call is ended. 
40: The event is forwarded to the application logic. 
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AppLoqic 



: IpAppCallLeq 



1 : event Report Req( ANSWER, REDIRECTED - NOTIFY 



IpCallLeq 



The Call and the Leg 
have already been 
created. 



routeReq( 



3: event Report Res ( REDIRECTED 



4: eventReportRes( ANSWER 



1: The application has already created the call and a call leg. It places an event report request for the ANSWER and 
REDIRECTED events in NOTIFY mode. 

2: The application routes the call leg. 

3: The call is redirected within the network and the application is informed. The new destination address is passed 
within the event. The event is not disarmed, so subsequent redirections will also be reported. Also, the same call leg is 
used so the application does not have to create a new one. 

4: The call is answered at its new destination. 



7.2 Class Diagrams 



The multiparty call control service consists of two packages, one for the interfaces on the appUcation side and one for 
interfaces on the service side. 

The class diagrams in the following figures show the interfaces that make up the multi party call control application 
package and the multi party call control service package. This class diagram shows the interfaces of the multi-party call 
control application package and their relations to the interfaces of the multi-party call control service package. 
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«lnterface» 
Iplnterface 

(from csapi) 



«lnterface» 
IpAppMultiPartyCallControl Manager 

(from mpccs) 



B''9PdNot'f'cation() 

"^allAbortedO 
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*managerResumed() 
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hangeNotificationO 
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«ln terface>> 
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0..n 
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%elease() 
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•setChargePlanO 
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0..n 



«lnterface» 
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*attachMediaRes() 
*attachMediaErr() 
•detach M ed i a Res() 
*detachMediaErr() 
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*getlnfoErr() 
•route Err() 
*superviseRes() 
*superviseErr() 

^callLegEndedO 



0..ri 

-> 



«lnterface» 
IpCallLeg 

(from mpccs) 

%outeReq() 
*eventReportReq() 
*release() 
*getlnfoReqO 
•getCallO 
*attachMediaReq() 
%ietachMediaReq() 
*getCurrentDesti nation AddressO 
*continueProcessing() 
*setChargePlan() 
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•superviseReqO 
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Figure: Application Interfaces 



This class diagram shows the interfaces of the multi-party call control service package. 
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<<lnterface» 
lpSer«ce 

{from csapi) 



*SetCallback() 
AetCallbackWith Session ID() 

A 



«lnterface>> 
IpCallLeg 

(from m pcc^ 



iWouteReqO 

*feventReportReq() 
%elease() 
Q p *QetlnfoReq() 
*SetCallO 
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*tietachMediaReq() 
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Figure: Service Interfaces 



7.3 MultiParty Call Control Service Interface Classes 

The Multi-party Call Control service enhances the functionality of the Generic Call Control Service with leg 
management. It also allows for multi-party calls to be established, i.e., up to a service specific number of legs can be 
connected simultaneously to the same call. 

The Multi-party Call Control Service is represented by the IpMultiPartyCallControlManager, IpMultiPartyCall, 
IpCallLeg interfaces that interface to services provided by the network. Some methods are asynchronous, in that they 
do not lock a thread into waiting whilst a transaction performs. In this way, the client machine can handle many more 
calls, than one that uses synchronous message calls. To handle responses and reports, the developer must implement 
IpAppMultiPartyCallControlManager, IpAppMultiPartyCall and IpAppCallLeg to provide the callback mechanism. 







<<lntertace» 
IpMultiPartyCall 

{from mpccs) 


<<lnterface» 
IpMultiPartyCallControlManager 

(from mpccs) 


1 0..r 


HetCallLegsO 
*CreateCallLeg() 
*CreateAndRouteCallLegReq() 
^eleaseO 
*deassignCall() 
*getlnfoReq() 
*6etChargePlan() 
*6etAdviceOfCharge() 
*SuperviseReq() 


■:reateCall() 

^;reateNotification() 
*tiestroyNotification() 
*ChangeNotification() 
*SetNotification() 

l^etCailLoadControlO 









7.3.1 Interface Class IpMultiPartyCallControlManager 

Inherits from: IpService 

This interface is the 'service manager' interface for the Multi-party Call Control Service. The multi-party call control 
manager interface provides the management functions to the multi-party call control service. The application 
programmer can use this interface to provide overload control functionality, create call objects and to enable or disable 
call-related event notifications. The action table associated with the STD shows in what state the 
IpMultiPartyCallControlManager must be if a method can successfully complete. In other words, if the 
IpMultiPartyCallControlManager is in another state the method will throw an exception immediately. 
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«lnterface» 
IpMultiPartyCallControlManager 



createCall (appCall : in IpAppMultiPartyCallRef) : TpMultiPartyCallldentifier 

createNotification (appCallControlManager : in IpAppMultiPartyCallControlManagerRef, notificationRequest 
: in TpCallNotification Request) : TpAssignmentID 

destroyNotification (assignmentID : in TpAssignmentID) : void 

cInangeNotification (assignmentID : in TpAssignmentID, notificationRequest : in TpCallNotificationRequest) : 
void 

getNotification () : TpNotificationRequestedSet 

setCallLoadControl (duration : in TpDuration, meclnanism : in TpCallLoadControlMechanism, treatment : in 
TpCallTreatment, addressRange : in TpAddressRange) : TpAssignmentID 



Method 

createCall () 

This method is used to create a new call object. An IpAppMultiPartyCaUControlManager should already have been 
passed to the IpMultiPartyCallControlManager, 

otherwise the call control will not be able to report a callAborted() to the application (the application should invoke 
setCallbackO if it wishes to ensure this). 

Returns callReference: Specifies the interface reference and sessionID of the call created. 
Parameters 

appCall : in IpAppMultiPartyCallRef 

Specifies the apphcation interface for callbacks from the call created. 

Returns 

TpMultiPartyCallldentifier 

Raises 

TpCommonExceptions , P_INVALID_INTERFACE_TYPE 

Method 

createNotification ( ) 

This method is used to enable call notifications so that events can be sent to the application. This is the first step an 
application has to do to get initial notifications of calls happening in the network. When such an event happens, the 
application will be informed by reportNotification(). In case the application is interested in other events during the 
context of a particular call session it has to use the createAndRouteCallLegReqO method on the call object or the 
eventReportReqO method on the call leg object. The application will get access to the call object when it receives the 
reportNotification(). (Note that createNotification() is not applicable if the call is setup by the application). 
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The createNotification method is purely intended for applications to indicate their interest to be notified when certain 
call events take place. It is possible to subscribe to a certain event for a whole range of addresses, e.g. the application 
can indicate it wishes to be informed when a call is made to any number starting with 800. 

If some application already requested notifications with criteria that overlap the specified criteria, the request is refused 
with P_INVALID_CRITERIA. The criteria are said to overlap if both originating and terminating ranges overlap and 
the same number plan is used. 

If a notification is requested by an application with monitor mode set to notify, then there is no need to check the rest of 
the criteria for overlapping with any existing request as the notify mode does not allow control on a call to be passed 
over. Only one application can place an interrupt request if the criteria overlaps. 

If the same application requests two notifications with exactly the same criteria but different callback references, the 
second callback will be treated as an additional callback. Both notifications will share the same assignmentlD. The 
gateway will always use the most recent callback. In case this most recent callback fails the second most recent is used. 
In case the enableCallNotification contains no callback, at the moment the application needs to be informed the gateway 
will use as callback the callback that has been registered by setCallback(). 

Returns assignmentlD: Specifies the ID assigned by the call control manager interface for this newly-enabled event 
notification. 

Parameters 

appCallControlManager : in IpAppMultiPartyCallCon'trolManagerRef 

If this parameter is set (i.e. not NULL) it specifies a reference to the application interface, which is used for callbacks. If 
set to NULL, the application interface defaults to the interface specified via the setCallback() method. 

notif icationReques't : in TpCallNotif ica'tionRequest 

Specifies the event specific criteria used by the application to define the event required. Only events that meet these 
criteria are reported. Examples of events are "incoming call attempt reported by network", "answer", "no answer", 
"busy". Individual addresses or address ranges may be specified for destination and/or origination. 

Returns 

TpAs s ignment I D 

Raises 

TpCommonExceptions, P_INVALID_CRITERIA, P_INVALID_INTERFACE_TYPE, 
P_INVALID_EVENT_TYPE 

Method 

destroyNotif ication 

This method is used by the application to disable call notifications. 

Parameters 

assignmentlD : in TpAssignmentID 

Specifies the assignment ID given by the generic call control manager interface when the previous enableNotification() 
was called. If the assignment ID does not correspond to one of the vaUd assignment IDs, the exception 
P_INVALID_ASSIGNMENTID will be raised. If two callbacks have been registered under this assignment ID both of 
them will be disabled. 
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Raises 

TpCommonExceptions , P_INVALID_ASSIGNMENT_ID 

Method 

changeNotif ication 

This method is used by the application to change the event criteria introduced with createNotification. Any stored 
criteria associated with the specified assignmentID will be replaced with the specified criteria. 

Parameters 

assignmentID : in TpAssignmentID 

Specifies the ID assigned by the generic call control manager interface for the event notification. If two callbacks have 
been registered under this assignment ID both of them will be changed. 

notif icationRequest : in TpCallNotif icationRequest 

Specifies the new set of event specific criteria used by the apphcation to define the event required. Only events that 
meet these criteria are reported. 

Raises 

TpCommonExceptions, P_INVALID_ASSIGNMENT_ID, P_INVALID_CRITERIA, 
P_INVALID_EVENT_TYPE 

Method 

getNotif ication () 

This method is used by the application to query the event criteria set with createNotification or changeNotification. 
Returns notificationsRequested: Specifies the notifications that have been requested by the application. 

Parameters 

No Parameters were identified for this method 
Returns 

TpNotif icationRequestedSet 

Raises 

TpCommonExceptions 

Method 

setCallLoadControl () 

This method imposes or removes load control on calls made to a particular address range within the call control service. 
The address matching mechanism is similar as defined for TpCaUEventCriteria. 

Returns assignmentID: Specifies the assignmentID assigned by the gateway to this request. This assignmentID can be 
used to correlate the callOverloadEncountered and callOverloadCeased methods with the request. 
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Parameters 

duration : in TpDuration 

Specifies the duration for which the load control should be set. 

A duration of indicates that the load control should be removed. 

A duration of -1 indicates an infinite duration (i.e., until disabled by the application) 

A duration of -2 indicates the network default duration. 

mechanism : in TpCallLoadControlMechanism 

Specifies the load control mechanism to use (for example, admit one call per interval), and any necessary parameters, 
such as the call admission rate. The contents of this parameter are ignored if the load control duration is set to zero. 

treatment : in TpCallTreatment 

Specifies the treatment of calls that are not admitted. The contents of this parameter are ignored if the load control 
duration is set to zero. 

addressRange : in TpAddressRange 

Specifies the address or address range to which the overload control should be applied or removed. 



Returns 

TpAssignmentID 

Raises 

TpCommonExceptions, P_INVALID_ADDRESS , P_UNSUPPORTED_ADDRESS_PLAN 



7.3.2 Interface Class IpAppMultiPartyCallControlManager 

Inherits from: Iplnterface 

The Multi-Party call control manager application interface provides the application call control management functions 
to the Multi-Party call control service. 
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«lnterface» 
IpAppMultiPartyCallControlManager 



reportNotification (callReference : in TpMultiPartyCallldentifier, callLegReferenceSet : in 

TpCallLegldentifierSet, notificationlnfo : in TpCallNotificationlnfo, assignmentID : in TpAssignmentID) : 
TpAppMultiPartyCallBack 

callAborted (callReference : in TpSessionID) : void 

managerlnterrupted () : void 

managerResumed () : void 

callOverloadEncountered (assignmentID : in TpAssignmentID) : void 
callOverloadCeased (assignmentID : in TpAssignmentID) : void 



Method 

reportNotification ( ) 

This method notifies the application of the arrival of a call-related event. 

If this method is invoked with a monitor mode of P_CALL_MONITOR_MODE_INTERRUPT, then the APL has 
control of the call. If the APL does nothing with the call (including its associated legs) within a specified time period 
(the duration of which forms a part of the service level agreement), then the call in the network shall be released and 
callEndedO shall be invoked, giving a release cause of P_TIMER_EXPIRY. 

Returns appCallBack: Specifies references to the application interface which implements the callback interface for the 
new call and/or new call leg. This parameter may be null if the notification is being given in NOTIFY mode. 

Parameters 

callReference : in TpMultiPartyCallldentifier 

Specifies the reference to the call interface to which the notification relates. This parameter will be null if the 
notification is being given in NOTIFY mode. 

callLegReferenceSet : in TpCallLegldentifierSet 

Specifies the set of all call leg references. First in the set is the reference to the originating callLeg. It indicates the call 
leg related to the originating party. In case there is a destination call leg this will be the second leg in the set. from the 
notificationlnfo can be found on whose behalf the notification was sent. 

However, this parameter will be null if the notification is being given in NOTIFY mode, 
notificationlnfo : in TpCallNotificationlnfo 

Specifies data associated with this event (e.g. the originating or terminating leg which reports the notification ). 
assignmentID : in TpAssignmentID 

Specifies the assignment id which was returned by the createNotification() method. The application can use assignment 
id to associate events with event specific criteria and to act accordingly. 
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Returns 

TpAppMult IP art y Cal IBack 

Method 

callAborted ( ) 

This method indicates to the appUcation that the call object has aborted or terminated abnormally. No further 
communication will be possible between the call and application. 

Parameters 

callRef erence : in TpSessionID 

Specifies the sessionID of caU that has aborted or terminated abnormally. 
Method 

managerlnterrupted ( ) 

This method indicates to the application that event notifications and method invocations have been temporarily 
interrupted (for example, due to network resources unavailable). 

Note that more permanent failures are reported via the Framework (integrity management). 
Parameters 

No Parameters were identified for this method 



Method 

managerResiuned ( ) 

This method indicates to the application that event notifications are possible and method invocations are enabled. 
Parameters 

No Parameters were identified for this method 



Method 

callOverloadEncountered ( ) 

This method indicates that the network has detected overload and may have automatically imposed load control on calls 
requested to a particular address range or calls made to a particular destination within the call control service. 

Parameters 

assignmentID : in TpAssignmentID 

Specifies the assigrmientID corresponding to the associated setCaULoadControl. This implies the addressrange for 
within which the overload has been encountered. 
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Method 

callOverloadCeased ( ) 

This method indicates that the network has detected that the overload has ceased and has automatically removed any 
load controls on calls requested to a particular address range or calls made to a particular destination within the call 
control service. 

Parameters 

assignmentID : in TpAssignmentID 

Specifies the assignmentID corresponding to the associated setCallLoadControl. This implies the addressrange for 
within which the overload has been ceased 



7.3.3 Interface Class IpMultiPartyCall 

Inherits from: IpService 

The Multi-Party Call provides the possibility to control the call routing, to request information from the call, control the 
charging of the call, to release the call and to supervise the call. It also gives the possibility to manage call legs 
explicitly. An application may create more then one call leg. 

«lnterface» 
IpMultiPartyCall 



getCallLegs (callSessionID : in TpSessionID) : TpCallLegldentifierSet 

createCallLeg (callSessionID : in TpSessionID, appCallLeg : in IpAppCallLegRef) : TpCallLegldentifier 

createAndRouteCallLegReq (callSessionID : in TpSessionID, eventsRequested : in 

TpCallEventRequestSet, targetAddress : in TpAddress, originatingAddress : in TpAddress, applnfo : in 
TpCallApplnfoSet, appLeg Interface : in IpAppCallLegRef) : TpCallLegldentifier 

release (callSessionID : in TpSessionID, cause : in TpReleaseCause) : void 

deassignCall (callSessionID : in TpSessionID) : void 

getlnfoReq (callSessionID : in TpSessionID, calllnfoRequested : in TpCalllnfoType) : void 

setChargePlan (callSessionID : in TpSessionID, callChargePlan : in TpCallChargePlan) : void 

setAdviceOfCharge (callSessionID : in TpSessionID, aOCInfo : in TpAoClnfo, tariffSwitch : in TpDuration) : 
void 

superviseReq (callSessionID : in TpSessionID, time : in TpDuration, treatment : in 
TpCallSuperviseTreatment) : void 



Method 

getCallLegs ( ) 

This method requests the identification of the call leg objects associated with the call object. Returns the legs in the 
order of creation. 
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Returns callLegList: Specifies the call legs associated with the call. The set contains both the sessionlDs and the 
interface references. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

Returns 

TpCallLegldentif ierSet 

Raises 

TpCommonExceptions , P_INVALID_SESSION_ID 

Method 

createCallLeg ( ) 

This method requests the creation of a new call leg object. 

Returns callLeg: Specifies the interface and sessionID of the call leg created. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

appCallLeg : in IpAppCallLegRef 

Specifies the appUcation interface for callbacks from the call leg created. 

Returns 

TpCallLegldentif ier 

Raises 

TpCommonExceptions, P_INVALID_SESSION_ID, P_INVALID_INTERFACE_TYPE 

Method 

createAndRouteCallLegReq ( ) 

This asynchronous operation requests creation and routing of a new callLeg. In case the connection to the destination 
party is established successfully the CallLeg is attached to the call, i.e. no explicit attachMediaReqO operation is 
needed. Requested events will be reported on the IpAppCallLeg interface. This interface the application must provide 
through the appLeglnterface parameter. 

The extra address information such as originatingAddress is optional. If not present (i.e., the plan is set to 
P_ADDRESS_PLAN_NOT_PRESENT), the information provided in corresponding addresses from the route is used, 
otherwise the network or gateway provided numbers will be used. 

If the application wishes that the call leg should be represented in the network as being a redirection it should include a 
value for the field P_CALL_APP_ORIGINAL_DESTINATION_ADDRESS of TpCallAppInfo. 
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If this method is invoked, and call reports have been requested, yet the IpAppCallLeg interface parameter is NULL, this 
method shall throw the P_NO_CALLBACK_ADDRESS_SET exception. 

Returns callLegReference: Specifies the reference to the CallLeg interface that was created. 
Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

eventsRequested : in TpCallEventRequestSet 

Specifies the event specific criteria used by the application to define the events required. Only events that meet these 
criteria are reported. Examples of events are "address analysed", "answer" and "release". 

targetAddress : in TpAddress 

Specifies the destination party to which the call should be routed. 

originatingAddress : in TpAddress 

Specifies the address of the originating (calling) party. 

applnfo : in TpCallAppInf oSet 

Specifies application-related information pertinent to the call (such as alerting method, tele-service type, service 
identities and interaction indicators). 

appLeglnterface : in IpAppCallLegRef 

Specifies a reference to the application interface that implements the callback interface for the new call leg. Requested 
events will be reported by the eventReportRes() operation on this interface. 

Returns 

TpCallLegldentifier 

Raises 

TpCommonExceptions, P_INVALID_SESSION_ID, P_INVALID_INTERFACE_TYPE, 
P_INVALID_ADDRESS , P_UNSUPPORTED_ADDRESS_PLAN, P_INVALID_NETWORK_STATE , 
P_INVALID_EVENT_TYPE , P_INVALID_CRITERIA 

Method 
release () 

This method requests the release of the call object and associated objects. The call will also be terminated in the 
network. If the application requested reports to be sent at the end of the call (e.g., by means of getlnfoReq) these reports 
will still be sent to the application. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

cause : in TpReleaseCause 

Specifies the cause of the release. 
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Raises 

TpCommonExceptions, P_INVALID_SESSION_ID, P_INVALID_NETWORK_STATE 

Method 

deassignCall () 

This method requests that the relationship between the application and the call and associated objects be de-assigned. It 
leaves the call in progress, however, it purges the specified call object so that the application has no further control of 
call processing. If a call is de-assigned that has call information reports, call leg event reports or call Leg information 
reports requested, then these reports wiU be disabled and any related information discarded. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

Raises 

TpCommonExceptions , P_INVALID_SESSION_ID 

Method 

getlnfoReqO 

This asynchronous method requests information associated with the call to be provided at the appropriate time (for 
example, to calculate charging). This method must be invoked before the call is routed to a target address. 

A report is received when the destination leg or party terminates or when the call ends. The call object will exist after 
the call is ended if information is required to be sent to the application at the end of the call. In case the originating party 
is still available the application can still initiate a follow-on call using routeReq. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

calllnfoRequested : in TpCall Info Type 

Specifies the call information that is requested. 

Raises 

TpCommonExceptions , P_INVALID_SESSION_ID 

Method 

setChargePlan ( ) 

Set an operator specific charge plan for the call. 
Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

callChargePlan : in TpCallChargePlan 

Specifies the charge plan to use. 
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Raises 

TpCommonExcept ions , P_INVALID_SESSION_ID 

Method 

setAdviceOf Charge ( ) 

This method allows for advice of charge (AOC) information to be sent to terminals that are capable of receiving this 
information. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

aOCInfo : in TpAoCInfo 

Specifies two sets of Advice of Charge parameter. 

tarif fSwitch : in TpDuration 

Specifies the tariff switch interval that signifies when the second set of AoC parameters becomes valid. 

Raises 

TpCommonExceptions, P_INVALID_SESSION_ID, P_INVALID_CURRENCY, 
P_INVALID_AMOUNT 

Method 

superviseReq ( ) 

The application calls this method to supervise a call. The application can set a granted connection time for this call. If 
an application calls this operation before it routes a call or a user interaction operation the time measurement will start 
as soon as the call is answered by the B-party or the user interaction system. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

time : in TpDuration 

Specifies the granted time in milliseconds for the connection. 

treatmen't : in TpCallSuperviseTreatment 

Specifies how the network should react after the granted connection time expired. 

Raises 

TpCommonExceptions , P_INVALID_SESSION_ID 



7.3.4 Interface Class IpAppMultiPartyCall 

Inherits from: Iplnterface 
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The Multi-Party call application interface is implemented by the client application developer and is used to handle call 
request responses and state reports. 

«lnterface» 
IpAppMultiPartyCall 



getlnfoRes (callSessionID : in TpSessionID, calllnfoReport : in TpCalllnfoReport) : void 

getlnfoErr (callSessionID : in TpSessionID, errorlndication : in TpCallError) : void 

superviseRes (callSessionID : in TpSessionID, report : in TpCallSuperviseReport, usedTime : in 
TpDuration) : void 

superviseErr (callSessionID : in TpSessionID, errorlndication : in TpCallError) : void 

callEnded (callSessionID : in TpSessionID, report : in TpCallEndedReport) : void 

createAndRouteCallLegErr (callSessionID : in TpSessionID, callLeg Reference : in TpCallLegldentifier, 
errorlndication : in TpCallError) : void 



Method 

getlnfoRes ( ) 

This asynchronous method reports time information of the finished call or call attempt as well as release cause 
depending on which information has been requested by getlnfoReq. This information may be used e.g. for charging 
purposes. The call information will possibly be sent after reporting of all cases where the call or a leg of the call has 
been disconnected or a routing failure has been encountered. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

calllnfoReport : in TpCalllnfoReport 

Specifies the call information requested. 

Method 

getlnfoErr ( ) 

This asynchronous method reports that the original request was erroneous, or resulted in an error condition. 
Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

errorlndication : in TpCallError 

Specifies the error which led to the original request failing. 
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Method 

superviseRes () 

This asynchronous method reports a call supervision event to the appUcation when it has indicated its interest in these 
kind of events. 

It is also called when the connection is terminated before the supervision event occurs. Furthermore, this method is 
invoked as a response to the request also when a tariff switch happens in the network during an active call. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call 

report : in TpCallSuperviseReport 

Specifies the situation which triggered the sending of the call supervision response. 
usedTime : in TpDuration 

Specifies the used time for the call supervision (in milliseconds). 
Method 

superviseErr ( ) 

This asynchronous method reports a call supervision error to the application. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

errorlndication : in TpCallError 

Specifies the error which led to the original request failing. 

Method 

callEndedO 

This method indicates to the application that the call has terminated in the network. 

Note that the event that caused the call to end might have been received separately if the application was monitoring for 
it. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call sessionlD. 

report : in TpCallEndedReport 

Specifies the reason the call is terminated. 
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Method 

createAndRouteCallLegErr ( ) 

This asynchronous method indicates that the request to route the call leg to the destination party was unsuccessful - the 
call leg could not be routed to the destination party (for example, the network was unable to route the call leg, the 
parameters were incorrect, the request was refused, etc.). Note that the event cases that can be monitored and 
correspond to an unsuccessful setup of a connection (e.g. busy, no_answer) will be reported by eventReportRes() and 
not by this operation. 

Parameters 

callSessionID : in TpSessionID 

Specifies the call session ID of the call. 

callLegReference : in TpCallLeglden-tif ier 

Specifies the reference to the CallLeg interface that was created. 

errorlndication : in TpCallError 

Specifies the error which led to the original request failing. 



7.3.5 Interface Class IpCallLeg 

Inherits from: IpService 

The call leg interface represents the logical call leg associating a call with an address. The call leg tracks its own states 
and allows charging summaries to be accessed. The leg represents the signalling relationship between the call and an 
address. An application that uses the IpCallLeg interface to set up connections has good control, e.g. by defining leg 
specific event request and can obtain call leg specific report and events. 
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«lnterface» 
IpCallLeg 



routeReq (callLegSessionID : in TpSessionID, targetAddress : in TpAddress, originatingAddress : in 
TpAddress, applnfo : in TpCallApplnfoSet, connectionProperties : in TpCallLegConnectionProperties) : 
void 

eventReportReq (callLegSessionID : in TpSessionID, eventsRequested : in TpCallEventRequestSet) : void 

release (callLegSessionID : in TpSessionID, cause : in TpReleaseCause) : void 

getlnfoReq (callLegSessionID : in TpSessionID, callLeglnfoRequested : in TpCallLeglnfoType) : void 

getCall (callLegSessionID : in TpSessionID) : TpMultiPartyCallldentifier 

attachMediaReq (callLegSessionID : in TpSessionID) : void 

detachMediaReq (callLegSessionID : in TpSessionID) : void 

getCurrentDestinationAddress (callLegSessionID : in TpSessionID) : TpAddress 

continueProcessing (callLegSessionID : in TpSessionID) : void 

setChargePlan (callLegSessionID : in TpSessionID, callChargePlan : in TpCallChargePlan) : void 

setAdviceOfCharge (callLegSessionID : in TpSessionID, aOCInfo : in TpAoClnfo, tariffSwitch : in 
TpDuration) : void 

superviseReq (callLegSessionID : in TpSessionID, time : in TpDuration, treatment : in 
TpCallLegSuperviseTreatment) : void 

deassign (callLegSessionID : in TpSessionID) : void 



Method 

routeReq ( ) 

This asynchronous method requests routing of the call leg to the remote party indicated by the targetAddress. 

In case the connection to the destination party is established successfully the CallLeg will be either detached or attached 
to the call based on the attach Mechanism values specified in the connectionProperties parameter. 

The extra address information such as originatingAddress is optional. If not present (i.e. the plan is set to 
P_ADDRESS_PLAN_NOT_PRESENT), the information provided in the corresponding addresses from the route is 
used, otherwise network or gateway provided addresses will be used. 

If the application wishes that the call leg should be represented in the network as being a redirection it should include a 
value for the field P_CALL_APP_ORIGINAL_DESTINATION_ADDRESS of TpCallAppInfo. 

This operation continues processing of the call leg. 
Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call leg. 

targetAddress : in TpAddress 

Specifies the destination party to which the call leg should be routed 

originatingAddress : in TpAddress 

Specifies the address of the originating (calling) party. 
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applnfo : in TpCallAppInf oSet 

Specifies application-related information pertinent to the call leg (such as alerting method, tele-service type, service 
identities and interaction indicators). 

connectionProperties : in TpCallLegConnec'tionProper'ties 

Specifies the properties of the connection. 

Raises 

TpCommonExceptions, P_INVALID_SESSION_ID, P_INVALID_NETWORK_STATE, 
P_INVALID_ADDRESS , P_UNSUPPORTED_ADDRESS_PLAN 

Method 

eventReportReq ( ) 

This asynchronous method sets, clears or changes the criteria for the events that the call leg object will be set to 
observe. 

Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call leg. 

event sReque St ed : in TpCallEventRequestSet 

Specifies the event specific criteria used by the apphcation to define the events required. Only events that meet these 
criteria are reported. Examples of events are "address analysed", "answer" and "release". 

Raises 

TpCommonExceptions, P_INVALID_SESSION_ID, P_INVALID_EVENT_TYPE, 
P_INVALID_CRITERIA 

Method 
release () 

This method requests the release of the call leg. If successful, the associated address (party) will be released from the 
call, and the call leg deleted. Note that in some cases releasing the party may lead to release of the complete call in the 
network. The application will be informed of this with callEnded(). 

This operation continues processing of the call leg. 
Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call leg. 

cause : in TpReleaseCause 

Specifies the cause of the release. 
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Raises 

TpCommonExceptions, P_INVALID_SESSION_ID, P_INVALID_NETWORK_STATE 

Method 

getlnfoReqO 

This asynchronous method requests information associated with the call leg to be provided at the appropriate time (for 
example, to calculate charging). Note that in the call leg information must be accessible before the objects of concern 
are deleted. 

Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call leg. 

callLeglnfoRequested : in TpCallLegInf oType 

Specifies the call leg information that is requested. 

Raises 

TpCommonExceptions , P_INVALID_SESSION_ID 

Method 
getCallO 

This method requests the call associated with this call leg. 

Returns callReference: Specifies the interface and sessionID of the call associated with this call leg. 
Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call leg. 

Returns 

TpMultiPartyCallldentif ier 

Raises 

TpCommonExceptions , P_INVALID_SESSION_ID 

Method 

attachMediaReq ( ) 

This method requests that the call leg be attached to its call object. This will allow transmission on all associated bearer 
connections or media streams to and from other parties in the call. The call leg must be in the connected state for this 
method to complete successfully. 

Parameters 

callLegSessionID : in TpSessionID 

Specifies the sessionID of the call leg to attach to the call. 
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Raises 

TpCommonExceptions, P_INVALID_SESSION_ID, P_INVALID_NETWORK_STATE 

Method 

detachMediaReq ( ) 

This method will detach the call leg from its call, i.e., this will prevent transmission on any associated bearer 
connections or media streams to and from other parties in the call. The call leg must be in the connected state for this 
method to complete successfully. 

Parameters 

callLegSessionID : in TpSessionID 

Specifies the sessionID of the call leg to detach from the call. 

Raises 

TpCommonExceptions, P_INVALID_SESSION_ID, P_INVALID_NETWORK_STATE 

Method 

getCurrentDestinationAddress () 

Queries the current address of the destination the leg has been directed to. 

Returns the address of the destination point towards which the call leg has been routed.. 

If this method is invoked on the Originating Call Leg, exception P_INVALID_STATE will be thrown. 

Parameters 

callLegSessionID : in TpSessionID 

Specifies the call session ID of the call leg. 

Returns 
TpAddress 

Raises 

TpCommonExceptions , P_INVALID_SESSION_ID 

Method 

continueP recessing ( ) 

This operation continues processing of the call leg. Applications can invoke this operation after call leg processing was 
interrupted due to detection of a notification or event the application subscribed its interest in. 

Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call leg. 
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Raises 

TpCommonExceptions, P_INVALID_SESSION_ID, P_INVALID_NETWORK_STATE 

Method 

setChargePlan ( ) 

Set an operator specific charge plan for the call leg. 
Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call party. 

callChargePlan : in TpCallChargePlan 

Specifies the charge plan to use. 

Raises 

TpCommonExceptions , P_INVALID_SESSION_ID 

Method 

setAdviceOfCharge ( ) 

This method allows for advice of charge (AOC) information to be sent to terminals that are capable of receiving this 
information. 

Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call party. 

aOCInfo : in TpAoCInfo 

Specifies two sets of Advice of Charge parameter. 

tariffSwitch : in TpDuration 

Specifies the tariff switch interval that signifies when the second set of AoC parameters becomes valid. 
Raises 

TpCommonExceptions, P_INVALID_SESSION_ID, P_INVALID_CURRENCY, 
P_INVALID_AMOUNT 

Method 

superviseReq ( ) 

The application calls this method to supervise a call leg. The application can set a granted connection time for this call. 
If an application calls this function before it calls a routeReqO or a user interaction function the time measurement will 
start as soon as the call is answered by the B -party or the user interaction system. 

Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call party. 
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time : in TpDuration 

Specifies the granted time in milliseconds for the connection. 

treatmen't : in TpCallLegSuperviseTrea'tment 

Specifies how the network should react after the granted connection time expired. 

Raises 

TpCommonExceptions , P_INVALID_SESSION_ID 

Method 

deassign 

This method requests that the relationship between the application and the call leg and associated objects be de- 
assigned. It leaves the call leg in progress, however, it purges the specified call leg object so that the application has no 
further control of call leg processing. If a call leg is de-assigned that has event reports or call leg information reports 
requested, then these reports will be disabled and any related information discarded. 

The application should not release or deassign the call leg when received a calILegEnded() or callEnded(). This 
operation continues processing of the call leg. 

Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call leg. 

Raises 

TpCommonExceptions , P_INVALID_SESSION_ID 



7.3.6 Interface Class IpAppCallLeg 

Inherits from: Iplnterface 

The application call leg interface is implemented by the chent application developer and is used to handle responses and 
errors associated with requests on the call leg in order to be able to receive leg specific information and events. 
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«lnterface» 
IpAppCallLeg 



eventReportRes (callLegSessionID : in TpSessionID, eventlnfo : in TpCallEventlnfo) : void 
eventReportErr (callLegSessionID : in TpSessionID, errorlndication : in TpCallError) : void 
attachMediaRes (callLegSessionID : in TpSessionID) : void 

attachMediaErr (callLegSessionID : in TpSessionID, errorlndication : in TpCallError) : void 
detachMediaRes (callLegSessionID : in TpSessionID) : void 

detachMediaErr (callLegSessionID : in TpSessionID, errorlndication : in TpCallError) : void 

getlnfoRes (callLegSessionID : in TpSessionID, callLeglnfoReport : in TpCallLeglnfoReport) : void 

getlnfoErr (callLegSessionID : in TpSessionID, errorlndication : in TpCallError) : void 

routeErr (callLegSessionID : in TpSessionID, errorlndication : in TpCallError) : void 

superviseRes (callLegSessionID : in TpSessionID, report : in TpCallSuperviseReport, usedTime : in 
TpDuration) : void 

superviseErr (callLegSessionID : in TpSessionID, errorlndication : in TpCallError) : void 
callLegEnded (callLegSessionID : in TpSessionID, cause : in TpReleaseCause) : void 



Method 

eventReportRes ( ) 

This asynchronous method reports that an event has occurred that was requested to be reported (for example, a mid-call 
event, the party has requested to disconnect, etc.). 

Depending on the type of event received, outstanding requests for events are discarded. The exact details of these so- 
called disarming rules are captured in the data definition of the event type. 

If this method is invoked for a report with a monitor mode of P_CALL_MONITOR_MODE_INTERRUPT, then the 
application has control of the call leg. If the application does nothing with the call leg within a specified time period 
(the duration which forms a part of the service level agreement), then the connection in the network shall be released 
and callLegEndedO shall be invoked, giving a release cause of P_TIMER_EXPIRY. 

Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call leg on which the event was detected. 

eventlnfo : in TpCallEventlnfo 

Specifies data associated with this event. 

Method 

eventReportErr ( ) 

This asynchronous method indicates that the request to manage call leg event reports was unsuccessful, and the reason 
(for example, the parameters were incorrect, the request was refused, etc.). 
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Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call leg. 

errorlndication : in TpCallError 

Specifies the error which led to the original request failing. 

Method 

attachMediaRes () 

This asynchronous method reports the attachment of a call leg to a call has succeeded. The media channels or bearer 
connections to this leg is now available. 

Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call leg to which the information relates. 
Method 

attachMediaErr ( ) 

This asynchronous method reports that the original request was erroneous, or resulted in an error condition. 
Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call leg. 

errorlndication : in TpCallError 

Specifies the error which led to the original request failing. 

Method 

detachMediaRes () 

This asynchronous method reports the detachment of a call leg from a call has succeeded. The media channels or bearer 
connections to this leg is no longer available. 

Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call leg to which the information relates. 
Method 

detachMediaErr ( ) 

This asynchronous method reports that the original request was erroneous, or resulted in an error condition. 
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Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call leg. 

errorlndication : in TpCallError 

Specifies the error which led to the original request failing. 

Method 

getlnfoRes () 

This asynchronous method reports all the necessary information requested by the application, for example to calculate 
charging. 

Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call leg to which the information relates. 

callLeglnfoReport : in TpCallLegInf oReport 

Specifies the call leg information requested. 

Method 

getlnfoErr 

This asynchronous method reports that the original request was erroneous, or resulted in an error condition. 
Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call leg. 

errorlndication : in TpCallError 

Specifies the error which led to the original request failing. 

Method 

routeErr ( ) 

This asynchronous method indicates that the request to route the call leg to the destination party was unsuccessful - the 
call leg could not be routed to the destination party (for example, the network was unable to route the call leg, the 
parameters were incorrect, the request was refused, etc.). 

Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call leg. 

errorlndication : in TpCallError 

Specifies the error which led to the original request failing. 
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Method 

superviseRes () 

This asynchronous method reports a call leg supervision event to the application when it has indicated its interest in 
these kind of events. 

It is also called when the connection to a party is terminated before the supervision event occurs. Furthermore, this 
method is invoked as a response to the request also when a tariff switch happens in the network during an active call. 

Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call leg 

report : in TpCallSuperviseReport 

Specifies the situation which triggered the sending of the call leg supervision response. 
usedTime : in TpDuration 

Specifies the used time for the call leg supervision (in milliseconds). 
Method 

superviseErr ( ) 

Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call leg. 

errorlndication : in TpCallError 

Specifies the error which led to the original request failing. 

Method 

callLegEnded ( ) 

This method indicates to the application that the leg has terminated in the network. The application has received all 
requested results (e.g., getlnfoRes) related to the call leg. The call leg will be destroyed after returning ftom this 
method. 

Parameters 

callLegSessionID : in TpSessionID 

Specifies the call leg session ID of the call leg. 

cause : in TpReleaseCause 

Specifies the reason the connection is terminated. 
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7.4 MultiParty Call Control Service State Transition Diagrams 
7.4.1 State Transition Diagrams for IpMultiPartyCallControlManager 



'^managerlnterrupted 




Figure : Application view and the Multi-Party Call Control Manager 

7.4.1.1 Active State 

In this state a relation between the Apphcation and the Service has been estabhshed. The state allows the application to 
indicate that it is interested in call related events. In case such an event occurs, the Manager will create a Call object 
with the appropriate number of Call Leg objects and inform the application. The application can also indicate it is no 
longer interested in certain call related events by calling destroyNotification(). 

7.4.1.2 Interrupted State 

When the Manager is in the Interrupted state it is temporarily unavailable for use. Events requested cannot be 
forwarded to the application and methods in the API cannot successfully be executed. A number of reasons can cause 
this: for instance the application receives more notifications from the network than defined in the Service Agreement. 
Another example is that the Service has detected it receives no notifications from the network due to e.g. a link failure. 
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7.4.1 .3 Overview of allowed methods 







Active 


createCall, 




createNotification, 




destroyNotification, 




changeNotification, 




getNotification, 




setCallLoadControl 


Interrupted 


getNotification 



7.4.2 State Transition Diagrams for IpMultiPartyCall 

The state transition diagram shows the appUcation view on the MultiParty Call object. 

When an IpMultiPartyCall is created using createCall, or when an IpMultiPartyCall is given to the application for a 
notification with a monitor mode of P_CALL_MONITOR_MODE_INTERRUPT, an activity timer is started. The 
activity timer is stopped when the apphcation invokes a method on the IpMultiPartyCall. The action upon expiry of this 
activity timer is to invoke callEnded() on the IpAppMultiPartyCall with a release cause of P_TIMER_EXPIRY. In the 
case when no IpAppMultiPartyCall is available on which to invoke calIEnded(), callAborted() shall be invoked on the 
IpAppMultiPartyCaUControlManager as this is an abnormal termination. 
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A timer mechanisem preventsthatthe object L 
keeps occupying resources. In case the ti mer 
expires, callEnded{)isinvotedon the 
IpAppM ul tiPartyCal I with a release cause of 
P_TIMER_EXPIRY. I n the case when no 
IpAppMultiPartyCall isavailableon whichto invoke 
callEndedO, callAbortedO ^lall be invoked on the 
I pAppM ul tiP artyCal ICon tro IManage r a st his is an 
abnormal termination. 



Figure : Application view on the MultiParty Call object 

7.4.2.1 IDLE State 

In this state the Call object has no Call Leg object associated to it. 

The application can request for charging related information reports, call supervision, set the charge plan and set Advice 
Of Charge indicators. When the first Call Leg object is requested to be created a state transition is made to the Active 
state. 

7.4.2.2 ACTIVE State 

In this state the Call object has one or more Call Leg objects associated to it. The application is allowed to create 
additional Call Leg objects. 

Furthermore, the application can request for call supervision. The Application can request charging related information 
reports, set the charge plan and set Advice Of Charge indicators in this state prior to call establishment. 

7.4.2.3 RELEASED State 

In this state the last Call leg object has released or the call itself was released. While the call is in this state, the 
requested call information will be collected and returned through getInfoRes() and / or superviseRes(). As soon as all 
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information is rehimed, the application will be informed that the call has ended and Call object transition to the end 
state. 



7.4.2.4 Overview of allowed methods 



Methods applicable 


Call Control Call State 


^^^^^^^^^^^ 


getCallLegs, 


Idle, Active, Released 




createCallLeg, 

createAndRouteCallLegReq, setAdviceOfCharge, superviseReq, 


Idle, Active 


Active 


release 


Active 


Active 


deassignCall 


Idle, Active 




setChargePlan, getlnfoReq 


Idle, Active 


Active 



7.4.3 State Transition Diagrams for IpCallLeg 

The IpCallLeg State Transition Diagram is divided in two State Transition Diagrams, one for the originating call leg 
and one for the terminating call leg. 

Call Leg State Model General Objectives: 

1) Events in backwards direction (upstream), coming from terminating leg, are not visible in originating leg model. 

2) Events in forwards direction (downstream), coming from originating leg, are not visible in terminating leg 
model. 

3) States are as seen from the application: if there is no change in the method an application is permitted to apply 
on the IpCallLeg object, then there is no state change. Therefore receipt of e.g. answer or alerting events on 
terminating leg do not change state. NOTE 2 

4) The application is to send a request to continue processing (using an appropriate method Uke 
continueProcessing) for each leg and event reported in monitor mode 'interrupt'. 

5) In case on a leg more than one network event (for example mid-call event 'service_code') is to be reported to the 
application at quasi the same time, then the events are to be reported one by one to the appUcation in the order 
received from the network. When for a leg an event is reported in interrupt mode, a next pending event is not to 
be reported to the application until a request to resume call processing for the current reported event has been 
received on the leg. 

NOTEl: CaU processing is suspended if for a leg a network event is met, which was requested to be monitored in 
tiie P_CALL_MONITOR_MODE_INTERRUPT. 

NOTE2: Even though there in the Originating Call Leg STD is no change in the methods the application is 
permitted to apply to the IpCallLeg object for the states Analysing and Active, separate states are 
maintained. The states may therefore from an apphcation viewpoint appear as just one state that may be 
have substates like Analysing and Active. The digit collection task in state Analysing state may be viewed 
as a specialised task that may not at all be applicable in some networks and therefore here described as 
being a state on its own. 

7.4.3.1 Originating Call Leg 
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Originating Call Leg. 



All States 



attactiMedia 
detachMedia 



Initiating 



Addrefes Collected' 

Address_Cdlected' 




IpAppM uiti PartyCal I Control M anag er 
reportNotification( originating Call Attempt 

IpAppMultlPartyCallControlManager. 
reportNotification( originatingCallAttemptAutliorized ) 



IpAppMultiPartvCallControlManaaer. 



reportNotification( address_collected ) 



originating servlce_code' 



IpAppMultiPartyCallControlManager. 
reportNotlficatlon( address_analised ) 



I pApp Mul tl FfertyCal I Co ntro I Ma nage r. 
reportNotlflcdion(or Igi naing ser\ice code) 



networkrelease' 



Rel easing 



do/ send reports if requested, or error reports if required 



IpAppMultiF^rtyCallControl Manager 



reportNotlficatlon( originating 
release ) 



deasign 



"IpAppCal I Leg .call Leg Ended 

Transitions/events not sfiovwi: 
All states: 

continueProcessIng, getLastRedirectedAddress, getCall: no state change 
All states except Releasing: 

eventReportReq, setAdviceOfCtiarge, getlnfoReq, superviseReq, 
setCtiargePlan 




Figure : Originating Leg 



7.4.3.1.1 Initiating State 

Entry events: 

Sending of a reportNotification() method by the IpMuhiPartyCallControlManager for an 
"Originating_Call_Attempt" initial notification criterion. 

Sending of a reportNotification() method by the IpMuhiPartyCallControlManager for an 
"Originating_Call_Attempt_Authorised" initial notification criterion. 
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Functions: 

In this state the network checks the authority /ability of the party to place the connection to the remote (destination) 
party with the given properties, e.g. based on the originating party's identity and service profile. 

The setup of the connection for the party has been initiated and the application activity timer is being provided. 

The figure below shows the order in which network events may be detected in the Initiating state and depending on the 
monitor mode be reported to the application. 




Note 1 : Event oCA only applicable as an initial notification . 

Note 2: The release event (oREL) can occur in any state resulting in a transition to Releasing state. 

Abbreviations used for the events: 

oCA: originating Call Attempt; oCAA originating Call Attempt Authorized; AC: Address Collected, oREL originating 
RELease. 

Figure : Application view on event reporting order in Initiating State 



In this state the following functions are applicable: 

- The detection of a "Originating_Call_Attempt" initial notification criterion. 

The detection of an "Originating_Call_Attempt_Authorised" initial notification criterion as a result that the call 
attempt authorisation is successful. 

- The report of the "Originating_Call_Attempt_Authorised" event indication whereby the following functions are 
performed: 

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event 
P_CALL_EVENT_CALL_ATTEMPT_AUTHORISED then the event is reported and call leg processing is 
suspended. 

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event 
P_CALL_EVENT_CALL_ATTEMPT_AUTHORISED then the event is notified and call leg processing 
continues. 

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event 
P_CALL_EVENT_CALL_ATTEMPT_AUTHORISED then no monitoring is performed. 

- The receipt of destination address information, i.e. initial information package/dialUng string as received from 
calling party. 

- Resumption of suspended call leg processing occurs on receipt of a continueProcessing() method. 
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Exit events: 

Availability of destination address information, i.e. the initial information package/dialling string received from 
the calling party. 

- Application activity timer expiry indicating that no requests from the apphcation have been received during a 
certain period. 

Receipt of a deassign() method. 
Receipt of a release() method. 

- Detection of a "originating release" indication as a result of a premature disconnect from the calling party. 

7.4.3.1.2 Analysing State 

Entry events: 

- Availabihty of an "Address_Collected" event indication as a result of the receipt of the (complete) initial 
information package/dialling string from the calling party. 

- Sending of a reportNotification() method by the IpMultiPartyCallControManager for an "Address_Collected" 
initial notification criterion. 

Functions: 

In this state the destination address provided by the calling party is collected and analysed. 

The received information (dialled address string from the calling party) is being collected and examined in accordance 
to the dialling plan in order to determine end of address information (digit) collection. Additional address digits can be 
collected. Upon completion of address collection the address is analysed. 

The address analysis is being made according to the dialling plan in force to determine the routing address of the call 
leg connection and the connection type (e.g. local, transit, gateway). 

The request (with eventReportReq method) to collect a variable number of more address digits and report them to the 
apphcation (within eventReportRes method)) is handled within this state. The collection of more digits as requested and 
the reporting of received digits to the application (when the digit collect criteria is met) is done in this state. This action 
is recursive, e.g. the apphcation could ask for 3 digits to be collected and when report request can be done repeatedly, 
e.g. the application may for example request first for 3 digits to be collected and when reported request further digits. 

The figure below shows the order in which network events may be detected in the Analysing state and depending on the 
monitor mode be reported to the application. 



oCAA 



Analysing 
State 



Notel 



AC 



OREL 



AA 



Note 1 : The release event (oREL) can occur in any state resulting in a transition to Releasing state. 
Abbreviations used for the events: 

oCAA: originating Call Attempt Authorized; AC: Address Collected; AA: Address Analysed; oREL: originating 
RELease. 



Figure : Application view on event reporting order in Analysing State 
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In this state the following functions are applicable: 

- The detection of a "Address_Collected" initial notification criterion. 

- On receipt of the "Address_Collected" indication the following functions are performed: 

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event 
P_CALL_EVENT_ADDRESS_COLLECTED then the event is reported and call leg processing is 
suspended. 

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event 
P_CALL_EVENT_ADDRESS_COLLECTED then the event is notified and call leg processing continues. 

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event 
P_CALL_EVENT_ADDRESS_COLLECTED then no monitoring is performed. 

- Receipt of a eventReportReqO method defining the criteria for the events the call leg object is to observe. 

- Resumption of suspended call leg processing occurs on receipt of a continueProcessingO or a routeReqO 
method. 

Exit events: 

- Detection of an "Address_Analysed" indication as a result of the availability of the routing address and nature 
of address. 

- Receipt of a deassign() method. 

- Receipt of a release() method. 

- Detection of a "originating release" indication as a result of a premature disconnect from the calling party. 

7.4.3.1.3 Active State 
Entry events: 

- Receipt of an "Address_Analysed" indication as a result of the availability of the routing address and nature of 
address. 

- Sending of a reportNotification() method by the IpMultiPartyCallControlManager for an "Address_Analysed 
initial indication criterion. 

Functions: 

In this state the call leg connection to the calling party exists and originating mid call events can be received. 

The figure below shows the order in which network events may be detected in the Active state and depending on the 
monitor mode be reported to the application. 
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Note 1 : Only the detected service code or the range to which the service code belongs is disarmed as the service 

code is reported to the application 
Note 2: The release event (oREL) can occur in any state resulting in a transition to Releasing state. 
Abbreviations used for the events: 

AC: Address Collected; AA: Address Analysed; oSC: originating Service Code; oREL: originating RELease. 
Figure : Application view on event reporting order Active State 



In this state the following functions are applicable: 

The detection of a Address_Analysed initial indication criterion. 

On receipt of the "Address_Analysed" indication the following functions are performed: 

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event 
P_CALL_EVENT_ADDRESS_ANALYSED then the event is reported and call leg processing is suspended. 

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event 
P_CALL_EVENT_ADDRESS_ANALYSED then the event is notified and call leg processing continues. 

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event 
P_CALL_EVENT_ADDRESS_ANALYSED then no monitoring is performed. 

Resumption of suspended call leg processing occurs on receipt of a continueProcessingO method. 

In this state the routing information is interpreted, the authority of the calling party to establish this connection is 
verified and the call leg connection is set up to the remote party. 

In this state a connection to the call party is established. 

Detection of a "terminating release" indication (not visible to the application) from remote party caused by a 
network release event propagated from a terminating party, possibly resulting in an "originating release" 
indication and causing the originating call leg STD to transit to Releasing state: 

Detection of a disconnect from the calling party. 

Receipt of a deassign() method. 

Receipt of a release() method. 

On receipt of the "originating_service code" indication the following functions are performed: 

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event 

P_CALL_EVENT_ORIGINATING_SERVICE_CODE then the event is reported and call leg processing is 
suspended. 
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ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event 
P_CALL_EVENT_ORIGINATING_SERVICE_CODED then the event is notified and call leg processing 
continues.. 

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event 
P_CALL_EVENT_ORIGINATING_SERVICE_CODE then no monitoring is performed. 

Resumption of suspended call leg processing occurs on receipt of a continueProcessingO method. 

Exit events: 

Detection of an "originating release" indication as a result of a disconnect from the calling party and a 
"terminating release" indication as a result of a disconnect from called party. 

Receipt of a deassign() method. 

Receipt of a release() method from the apphcation. 

7.4.3.1.4 Releasing State 

Entry events: 

Detection of an "Originating_Release" indication as a result of the network release initiated by calling party or 
called party. 

Reception of the release() method from the application. 

A transition due to fault detection to this state is made when the Call leg object is in a state and no requests from 
the application have been received during a certain time period (timer expiry). 

Functions: 

In this state the connection to the call party is released as requested by the network or by the application and the reports 
are processed and sent to the application if requested. 

When the Releasing state is entered the order of actions to be performed is as follows: 

i) the network release event handling is performed. 

ii) the possible call leg information requested with getlnfoReqO and/ or superviseReqO is collected and send to 
the application. 

iii) the callLegEnded() method is sent to the application to inform that the call leg object is destroyed. 

In this state the following functions are applicable: 

The detection of a "originating_release" initial indication criterion.. 
On receipt of the "originating_release" indication the following functions are performed: 
The network release event handling is performed as follows: 

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event 
P_CALL_EVENT_RELEASE then the event is reported and call leg processing is suspended. 

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event 
P_CALL_EVENT_RELEASE then the event is notified and call leg processing continues. 

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event 
P_CALL_EVENT_RELEASE then no monitoring is performed. 

Resumption of suspended call leg processing occurs on receipt of a continueProcessingO method. 

The possible call leg information requested with the getlnfoReqO and/or superviseReqO is collected and sent to 
the application with respectively the getInfoRes() and/or superviseRes() methods. 
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The callLegEndedO method is sent to the application after all information has been sent. In case that the 
application has not requested additional call leg related information the call leg object is destroyed immediately 
and additionally the application will also be informed that the connection has ended 

In case of abnormal termination due to a fault and the appUcation requested for call leg related information 
previously, the application will be informed that this information is not available and additionally the 
application is informed that the call leg object is destroyed (callLegEnded). 

Note: the call in the network may continue or be released, depending e.g. on the call state. 

In case the release() method is received in Releasing state it will be discarded. The request from the application 
to release the leg is ignored in this case because release of the leg is already ongoing. 

Exit events: 

- In case that the application has not requested additional call leg related information the call leg object is 
destroyed immediately and additionally the application is informed that the call leg cormection has ended, by 
sending the callLegEnded() method. 

- After the sending of the last call leg information to the application the Call Leg object is destroyed and 
additionally the appUcation is informed that the call leg connection has ended, by sending the callLegEnded() 
method. 

7.4.3.1 .5 Overview of allowed methods, Originating Call Leg STD 
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Initiating 


attachlVlediaReq (as a request), 
detachlVlediaReq, (as a request) 
getCall , 

contlnueProcessing, 

release (call leg), 

deassign 

eventReportReq, 

getlnfoReq, 

setChargePlan, 

setAdviceOfCharge, 

superviseReq 


Analysing 


attachMediaReq (as a request), 
detachMediaReq, (as a request) 
getCall , 

contlnueProcessing, 

release (call leg), 

deassign 

eventReportReq, 

getlnfoReq, 

setCliargePlan, 

setAdviceOfCharge, 

superviseReq 


Active 


attachlVlediaReq, 
detachMediaReq, 
getCall, 

contlnueProcessing, 

release 

deassign 

eventReportReq, 

getlnfoReq, 

setChargePlan, 

setAdviceOfCharge, 

superviseReq 


Releasing 


getCall , 

continueProcessing, 

release 

deassign 



7.4.3.2 Terminating Call Leg 
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Terminating Call Leg. 



All States 
(terminating) 



Idle 
(terminating) 



routeReq 



'terminating call attempt authorized' 
'alerting', 'answer', 'terminating senjice; ' 
code', 'redirected', 'queued' 

Active 

attactiMedia ^^--^ " (terminating) 
detactiMedIa 



'network 



release' 



release 



Releasing (tennlnatlng) 



t)M uiti Part yCall .0 reat eCall Ljeg 



^AppM uiti PartyCallControl Manager.r 
eportNotlflcation( "terminating call 
attempt", "terminating call attempt 
authorised", "alerting", "answer", 
"terminating sendee code", 
"redirected", "queued" ) 



IpMultlPartyCall.createAndRiiuteCallLegReq 



timer expiry' do/ send reports if requested, or error reports if require. 



"IpAppMultiPartyCallControlManager. 
reportNotificatlon( terminating 



*lpAppCallLeg.callLegEnded 



deasign 



Transitions/events not shown: 
All states: 

contlnueProcessing, getLastRedirectedAddress, getCall, sending getlnfoRes, 
supenyiseRes: no state change. 
All states except Releasing: 

eventReportReq, setAdvlceOfCharge, getlnfoReq, supemseReq, setChargePlan. 

When the application is notified in reportNotflcatlon of an call related network event 
associated with the Terminating Call Leg STD, then the Originating Call Leg STD is 
created and is initialized to be in the Active state. 



Figure : Terminating Leg 

7.4.3.2.1 Idle (terminating) State 

Entry events: 

Receipt of a createCallLegO method to start an application initiated call leg connection. 
Functions: 

In this state the call leg object is created and the interface connection is idled. 
The application activity timer is being provided. 



In this state the follo'wing functions are applicable: 

Invoking routeReq ■will result in a request to actually route the call leg object. 

Resumption of call leg processing occurs on receipt of a routeReqO method. 
Exit events: 
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- Receipt of a routeReqO method from the application. 

- Application activity timer expiry indicating that no requests from the apphcation have been received during a 
certain period to continue processing. 

- Receipt of a deassign() method. 

- Receipt of a release() method. 

- Detection of a network release event being an "originating release" indication as a result of a premature disconnect 
from the calling party. 



7.4.3.2.2 Active (terminating) State 

Entry events: 

Receipt of an routeReq will result in actually routing the call leg object. 

Receipt of a createAndRouteCallLegReqO method to start an application initiated call leg connection. 

Sending of a reportNotification() method by the IpMultiPartyCallControlManager for the following trigger 
criteria: "Terminating_Call_Attempt", "Terminating_Call_Attempt_Authorised", "Alerting", "Answer", 
"Terminating service code", "Redirected" and "Queued". 

Functions: 

In this state the routing information is interpreted, the authority of the called party to establish this connection is verified 
for the call leg connection. In this state a connection to the call party is established whereby events from the network 
may indicate to the apphcation when the party is alerted (acknowledge connection setup) and when the party answer 
(confirmation of cormection setup). 

Furthermore, in this state terminating service code events can be received. 

The figure below shows the order in which network events may be detected in the Active state and depending on the 
monitor mode be reported to the application. 




Note 1 : Event tCA applicable as initial notification 

Note 2: Only the detected service code or the range to which the service code belongs is disarmed as the service 

code is reported to the application 
Note 3: The release event (tREL) can occur in any state resulting in a transition to Releasing state. 
Abbreviations used for the events: 

tCA: Terminating Call Attempt; tCAA: terminating Call Attempt Authorized; AL: Alerting; ANS: Answer; tREL: 
terminating RELease; Q: Queued; RD: ReDirected; tSC: terminating Service Code. 

Figure : Application view on event reporting order in Active State 
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In this state the following functions are applicable: 

- The detection and report of the "Tern]inating_Call_Attempt_Authorised" event indication whereby the following 
functions are performed: 

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event 
P_CALL_EVENT_TERMINATING_CALL_ATTEMPT_AUTHORISED then the event is reported and call 
leg processing is suspended. 

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event 
P_CALL_EVENT_TERMINATING_CALL_ATTEMPT_AUTHORISED then the event is notified and call 

leg processing continues. 

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event 
P_CALL_EVENT_CALL_TERMINATING_ATTEMPT_AUTHORISED then no monitoring is performed. 

Detection of an "Queued" indication as a result of the terminating call being queued. 

- On receipt of the "Queued" indication the following functions are performed: 

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event 
P_CALL_EVENT_QUEUED then the event is reported and call leg processing is suspended. 

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event 
P_CALL_EVENT_QUEUED then the event is notified and call leg processing continues. 

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event 
P_CALL_EVENT_QUEUED then no monitoring is performed. 

- On receipt of the "Alerting" indication the following functions are performed: 

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event 
P_CALL_EVENT_ALERTING then the event is reported and call leg processing is suspended. 

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event 
P_CALL_EVENT_ALERTING then the event is notified and call leg processing continues. 

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event 

P_CALL_EVENT_ALERTING then no monitoring is performed. 

Detection of an "Answer" indication as a result of the remote party being connected (answered). 

- On receipt of the "Answer" indication the following functions are performed: 

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event 
P_CALL_EVENT_ANSWER then the event is reported and call leg processing is suspended. 

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event 
P_CALL_EVENT_ANSWER then the event is notified and call leg processing continues. 

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event 
P_CALL_EVENT_ANSWER then no monitoring is performed. 

- The detection of a "service_code" trigger criterion suspends call leg processing. 

- On receipt of the "service code" indication the following functions are performed: 

i) When the P_CALL_MONITOR_MODE_lNTERRUPT is requested for the call leg event 
P_CALL_EVENT_TERMINATING_SERVICE_CODE then the event is reported and call leg processing is 
suspended. 

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event 
P_CALL_EVENT_TERMINATING_SERVICE_CODE then this is not a vahd event (that event is not 
notified) and call leg processing continues. 
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iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event 
P_CALL_EVENT_TERMINATING_SERVICE_CODE then no monitoring is performed. 

On receipt of the "redirected" indication the following functions are performed: 

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event 
P_CALL_EVENT_REDIRECTED then the event is reported and call leg processing is suspended. 

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event 
P_CALL_EVENT_REDIRECTED then the event is notified and call leg processing continues. 

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event 
P_CALL_EVENT_REDIRECTED then no monitoring is performed. 

- Resumption of call leg processing occurs on receipt of a continueProcessing() method. 
Exit events: 

- Detection of a network release event being an "terminating release" indication as a result of the following 
events: 

i) Unable to select a route or indication from the remote party of the call leg connection cannot be presented 
(this is the network determined busy condition) 

ii) Occurrence of an authorisation failure when the authority to place the call leg connection was denied (e.g. 
business group restriction mismatch). 

iii) Detection of a route busy condition received from the remote call leg connection portion. 

iv) Detection of a no-answer condition received from the remote call leg connection portion. 

v) Detection that the remote party was not reachable. 

- Detection of a network release event being an "originating release" indication as a result of the following events: 

vi) Detection of a premature disconnect from the calUng party. 
Receipt of a deassign() method. 

- Receipt of a release() method from the appUcation. 

Detection of a network release event being an "originating release" indication as a result of a disconnect from 
the calling party or a "terminating release" indication as a result of a disconnect from the called party. 

7.4.3.2.3 Releasing (terminating) State 
Entry events: 

- Detection of a network release event being an "originating release" indication as a result of the network release 
initiated by calling party or a "terminating release" indication as a result of the network release initiated by 
called party.. 

- Sending of the release() method by the application. 

A transition due to fault detection to this state is made when the Call leg object awaits a request from the 
application and this is not received within a certain time period. 

Detection of a network event being a "terminating release" indication as a result of the following events: 

i) Unable to select a route or indication from the remote party of the call leg connection cannot be presented 
(this is the network determined busy condition) 

ii) Occurrence of an authorisation failure when the authority to place the call leg connection was denied (e.g. 
business group restriction mismatch). 
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iii) Detection of a route busy condition received from the remote call leg connection portion. 

iv) Detection of a no-answer condition received from the remote call leg connection portion. 

v) Detection that the remote party was not reachable. 

- Detection of a network release event being an "originating release" indication as a result of the following events: 

vi) Detection of a premature disconnect from the calUng party. 
Functions: 

In this state the connection to the call party is released as requested by the network or by the application 
and the reports are processed and sent to the application if requested . 

When the Releasing state is entered the order of actions to be performed is as follows: 

i) the release event handling is performed. 

ii) the possible call leg information requested with getlnfoReqO and/ or superviseReqO is collected and send to the 
application. 

iii) the callLegEnded() method is sent to the application to inform that the call leg object is destroyed. 

Where the entry to this state is caused by the application, for example because the apphcation has requested the leg to 
be released or deassigned or a fault (e.g. timer expiry, no response from application) has been detected, then i) is not 
apphcable. In the fault case for action ii) error report methods are sent to the application for any possible requested 
reports. 

In this state the following functions are applicable: 

The detection of a "Terminating Release" trigger criterion. 

- On receipt of the network release event being a "Terminating Release" indication the following functions are 
performed: 

- The network release event handhng is performed as follows: 

i) When the P_CALL_MONITOR_MODE_INTERRUPT is requested for the call leg event 
P_CALL_EVENT_TERMINATING_RELEASE then the event is reported and call leg processing is 
suspended. 

ii) When the P_CALL_MONITOR_MODE_NOTIFY is requested for the call leg event 
P_CALL_EVENT_TERMINATING_RELEASE then the event is notified and call leg processing 
continues. 

iii) When the P_CALL_MONITOR_MODE_DO_NOT_MONITOR is requested for the call leg event 
P_CALL_EVENT_TERMINATING_RELEASE then no monitoring is performed. 

Resumption of suspended call leg processing occurs on receipt of a continueProcessingO method. 

The possible call leg information requested with the getlnfoReqO and/or superviseReqO is collected and sent to 
the apphcation with respectively the getInfoRes() and/or superviseRes() methods. 

The callLegEndedO method is sent to the application after all information has been sent. In case that the 
application has not requested additional call leg related information the call leg object is destroyed immediately 
and additionally the apphcation will also be informed that the connection has ended 

In case of abnormal termination due to a fault and the application requested for call leg related information 
previously, the application will be informed that this information is not available and additionally the 
apphcation is informed that the call leg object is destroyed (caULegEnded). 

Note: the call in the network may continue or be released, depending e.g. on the call state. 

In case the release() method is received in Releasing state it will be discarded. The request from the 
application to release the leg is ignored in this case because release of the leg is already ongoing. 
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Exit events: 

In case that the application has not requested additional call leg related information the call leg object is 
destroyed immediately and additionally the application is informed that the call leg connection has ended, by 
sending the callLegEnded() method. 

- After the sending of the last call leg information to the application the Call Leg object is destroyed and 

additionally the application is informed that the call leg connection has ended, by sending the callLegEndedO 
method. 



7.4.3.2.4 Overview of allowed methods and trigger events, Terminating Call Leg STD 





Methods allowed 


Idle 


routeReq, 
getCall , 

getCurrentDestinationAddress, 

release, 

deassign 

eventReportReq, 

getlnfoReq, 

setChargePlan, 

setAdvlceOfCharge, 

superviseReq 


Active 


attachMediaReq 
detachMediaReq 
getCall , 

getCurrentDestinationAddress, 

contlnueProcessing, 

release, 

deassign 

eventReportReq, 

getlnfoReq, 

setChargePlan, 

setAdvlceOfCharge, 

superviseReq 


Releasing 


getCall , 

getCurrentDestinationAddress, 

continueProcessing, 

release, 

deassign 



7.5 Multi-Party Call Control Service Properties 
7.5.1 List of Service Properties 

The following table lists properties relevant for the MPCC API. These properties are additional to the properties of the 
GCC, from which the MPCC is an extension. 
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P_MAX_CALLLEGS_PER_CALL 


INTEGER_SET 


Indicates how many parties can be in one call. 


P_UI_CALLLEG_BASED 


BOOLEAN_SET 


Value = TRUE : User interaction can be performed on leg level and a 
reference to a CallLeg object can be used in the 
IpUIManager.createUICallO operation. 
Value = FALSE : No user interaction on leg level is supported. 


p RnimNn with rATTTFr; opfrattons 




V alLlC — 1 1\ \,J 1 ^ . IIIC CllVJllllV^ VJUCl CllUJllS iVJi IVJLlllllg Cl V^diiLiCg oLC aLlULUJllCU 

{IpMultiPartyCall.createCallLegO, IpCallLeg.eventReportReqO, 

IpCallLeg.routeReqO, IpCallLeg.attachMediaReqO ) 

Value = FALSE : the convenience function has to be used for routing a 

CallLeg. 


P_MEDIA_ATTACH_EXPLICn' 


BOOLEAN_SET 


Value = TRUE : the CallLeg shall be expUcitly attached to a Call. 
Value = FALSE : the CaULeg is automatically attached to a Call, no 
IpCallLeg.attachMediaReqO is needed when a party answers. 



7.5.2 Service Property values for the CAMEL Service Environment. 

Implementations of the MultiParty Call Control API relying on the CSE of CAMEL phase 3 shall have the Service 
Properties outlined above set to the indicated values : 

P_OPERATION_SET = { 

"IpMultiPartyCallControlManager . createNotification", 

"IpMultiPartyCallControlManager . destroyNotif ication", 

"IpMultiPartyCallControlManager . changeNotification", 

"IpMultiPartyCallControlManager . getNot if icat ion" , 

"IpMultiPartyCallControlManager . setCallLoadControl" 

"IpMultiPartyCall . getCallLegs", 

"IpMultiPartyCall . createCallLeg" , 

"IpMultiPartyCall . createAndRouteCallLegReq", 

"IpMultiPartyCall .release" , 

"IpMultiPartyCall . deassignCall", 

"IpMultiPartyCall . getlnfoReq", 

"IpMultiPartyCall . setChargePlan", 

"IpMultiPartyCall . setAdviceOf Charge" , 

"IpMultiPartyCall . superviseReq", 

"IpCallLeg . routeReq", 

"IpCallLeg . eventReportReq", 

"IpCallLeg. release", 

"IpCallLeg . getlnfoReq", 

"IpCallLeg. getCall", 

"IpCallLeg . continueProcessing" 

} 

P_TRIGGERING_EVENT_TYPES = { 
P_CALL_EVENT_ADDRESS_COLLECTED, 
P_C AL L_E VE NT_ADDRESS_ANALYSED, 
P_CALL_EVENT_ORIGINATING_RELEASE, 

P_CALL_EVENT_TERMINATING_CALL_ATTEMPT_AUTHORISED, 

P_CALL_EVENT_TERMINATING_RELEASE 

} 

Note: P_CALL_EVENT_ORIGINATING_RELEASE only for the routing failure case, TpReleaseCause = 

P_ROUTING_FAILURE 



P_DYNAMIC_EVENT_TYPES = { 

P_C AL L_E VE NT_ANSWER, 

P_CALL_EVENT_ORIGINATING_RELEASE, 

P_CALL_EVENT_TERMINATING_RELEASE 

} 

P_ADDRESS_PLAN = { 
P_ADDRESS_PLAN_E1 64 
} 

P_UI_CALL_BASED = { 

TRUE 

) 

P_UI_AT_ALL_STAGES = { 

FALSE 

} 
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P_MEDIA_TYPE = { 

P_AUDIO 

} 

P_MAX_CALLLEGS_PER_CALL = { 

0, 

2 

} 

P_UI_CALLLEG_BASED = { 

FALSE 

} 

P_MEDIA_ATTACH_EXPLICIT = { 

FALSE 

} 
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7.6 Multi-Party Call Control Data Definitions 

This clause provides the MPCC data definitions necessary to support the API specification. 
The general format of a data definition specification is described below. 

• Data Type 

This shows the name of the data type. 

• Description 

This describes the data type. 

• Tabular Specification 

This specifies the data types and values of the data type. 

• Example 

If relevant, an example is shown to illustrate the data type. 

All data types referenced but not defined in this clause are either in the common call control data definitions clause of 
the present document (clause 8) or in the cormnon data definitions which may be found in 3GPP TS 29.198-2. 

7.6.1 Event Notification Data Definitions 

No specific event notification data defined. 

7.6.2 Multi-Party Call Control Data Definitions 

7.6.2.1 IpCallLeg 

Defines the address of an IpCallLeg Interface. 

7.6.2.2 IpCallLegRef 

Defines a Reference to type IpCallLeg. 

7.6.2.3 IpAppCallLeg 

Defines the address of an IpAppCallLeg Interface. 

7.6.2.4 IpAppCallLegRef 

Defines a Reference to type IpAppCallLeg. 

7.6.2.5 IpMultiPartyCall 

Defines the address of an IpMultiPartyCall Interface. 

7.6.2.6 IpMultiPartyCallRef 

Defines a Reference to type IpMultiPartyCall. 

7.6.2.7 IpAppMultiPartyCall 

Defines the address of an IpAppMultiPartyCall Interface. 
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7.6.2.8 IpAppMultiPartyCallRef 

Defines a Reference to type IpAppMultiPartyCall. 

7.6.2.9 IpMultiPartyCallControlManager 

Defines the address of an IpMultiPartyCallControlManager Interface. 

7.6.2.1 IpMultiPartyCallControlManagerRef 

Defines a Reference to type IpMultiPartyCallControlManager. 

7.6.2.1 1 IpAppMultiPartyCallControlManager 

Defines the address of an IpAppMultiPartyCallControlManager Interface. 

7.6.2.12 IpAppMultiPartyCallControlManagerRef 

Defines a Reference to type IpAppMultiPartyCallControlManager.. 

7.6.2.13 TpAppCallLegRefSet 

Defines a Numbered Set of Data Elements of IpAppCaULegRef. 

7.6.2.14 TpMultiPartyCallldentifier 



Defines the Sequence of Data Elements that unambiguously specify the Call object 



Sequence Element 
Name 


Sequence Element 

Type 1 L 


Sequence Element 


CallRef erence 


IpMultiPartyCallRef 


This element specifies the interface reference for the Multi-party call object. 


CallSessionID 


TpSessionID 


This element specifies the call session ID. 



7.6.2.15 TpAppMultiPartyCallBack 

Defines the Tagged Choice of Data Elements that references the application callback interfaces 











TpAppMultiPartyCallBackRef Type 





Tag Elem i iil \l iiij|||^^^^^jMU|m|||- Flrmrnt "Jl^JBjl^Jlpirtirr Element Name 



P_APP_CALLBACK_UNDEFINED 


NULL 


Undefined 


P_APP_MULTIPARTY_CALL_CALLBACK 


IpAppMultiPartyCallRef 


AppMultiPartyCall 


P_APP_CALL_LEG_CALLBACK 


IpAppCallLegRef 


AppCallLeg 


P_APP_CALL_AND_CALL_LEG_CALLBACK 


TpAppCallLegCalffiack 


AppMultiPartyCallAndCallLeg 
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7.6.2.1 6 TpAppMultiPartyCallBackRefType 



Defines the type application call back interface. 





Value 




P_APP_CALLBACK_UNDEFINED 





Application Call back interface undefined 


P_APP_MULTIPARTY_CALL_CALLBACK 


1 


Application Multi-Party Call interface 
referenced 


P_APP_CALL_LEG_CALLBACK 


2 


Application CallLeg interface referenced 


P_APP_CALL_AND_CALL_LEG_CALLBACK 


3 


Application Multi-Party Call and CallLeg 
interface referenced 



7.6.2.17 TpAppCallLegCallBack 



Defines the Sequence of Data Elements that references a call and a call leg appUcation interface. 



^^H^ence Element Name 


Sequence Element Type 




AppMultiPartyCall 


IpAppMultiPartyCallRef 




AppCallLegSet 


TpAppCallLegRefSet 


Specifies the set of all call leg call back 
references. First in the set is the reference 
to the call back of the originating callLeg. 
In case there is a call back to a destination 
call leg this will be second in the set. 



7.6.2.18 TpMultiPartyCallldentifierSet 

Defines a Numbered Set of Data Elements of TpMultiPartyCallldentifier. 

7.6.2.19 TpCallApplnfo 



Defines the Tagged Choice of Data Elements that specify apphcation-related call information. 





Tag Element Type 






TpCallAppInf oType 





Tag Element ^^^^ 
Value 


Choice Element 
Type 


Choice Element ^^^_J 
Name ^^^11 


P_C AL L_AP P_ALERTIN G_ME CH AN I SM 


TpCallAlertingMechanism 


CallAppAlertingMechanism 


P_CALL_APP_NETWORK_ACCESS_TYPE 


TpCallNetworkAccessType 


CallAppNetworkAccessType 


P_CALL_APP_TELE_SERVICE 


TpCallTeleService 


CallAppTele Service 


P_CALL_APP_BEARER_SERVICE 


TpCallBearer Service 


CallAppBearer Service 


P_CALL_APP_PARTY_CATEGORY 


TpCallPartyCategory 


CallAppPartyCategory 


P_CALL_APP_PRESENTATION_ADDRESS 


TpAddress 


CallAppPresentat ionAddress 


P_C AL L_AP P_GENERIC_INFO 


TpString 


CallAppGenericInf o 


P_C AL L_AP P_ADD I T I ONAL_ADDRE S S 


TpAddress 


CallAppAdditionalAddress 


P_CALL_APP_ORIGINAL_DESTINATION_ADDRESS 


TpAddress 


CallAppOriginalDestinat ionAddress 


P_C AL L_AP P_RE D I RE C T I N G_AD D RE S S 


TpAddress 


CallAppRedirectingAddress 
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7.6.2.20 TpCallApplnfoType 



Defines the type of call application-related specific information. 



Name 


Value 


Description 


P_CALL_APP_UNDEFINED 





Undefined 


P_CALL_APP_ALERTING_MECHANISM 


1 


The alerting mechanism or pattern to use 


P_CALL_APP_NETWORK_ACCESS_TYPE 


2 


The network access type (e.g. ISDN) 


P_CALL_APP_TELE_SERVICE 


3 


Indicates the tele-service (e.g. telephony) 


P_CALL_APP_BEARER_SERVICE 


4 


Indicates the bearer service (e.g. 64 kbit/s unrestiicted data). 


P_CALL_APP_PARTY_CATEGORY 


5 


The category of the calling party 


P_CALL_APP_PRESENTATION_ADDRESS 


6 


The address to be presented to other call parties 


P_CALL_APP_GENERIC_INFO 


7 


Carties unspecified service-service information 


P_CALL_APP_ADDITIONAL_ADDRESS 


8 


Indicates an additional address 


P_C AL L_AP P_OR I G I N AL_D ESTINATI ON_AD D RE S S 


9 


Contains the original address specified by the originating user when 
launching the call. 


P_C AL L_AP P_REDIRECTIN G„AD DRESS 


10 


Contains the address of the user from which the call is diverting. 



7.6.2.21 TpCallApplnfoSet 

Defines a Numbered Set of Data Elements of TpCallAppInfo. 



7.6.2.22 TpCallEventRequest 



Defines the Sequence of Data Elements that specify the criteria relating to call report requests. 



Sequence Element Name 


Sequence Element Type 


CallEventType 


TpCallEventType 


Addit ionalCallEventCriteria 


TpAdditionalCallEventCriteria 


CallMonitorMode 


TpCallMonitorMode 



7.6.2.23 TpCallEventRequestSet 

Defines a Numbered Set of Data Elements of TpCallEventRequest. 
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7.6.2.24 TpCallEventType 



Defines a specific call event report type. 





Value 




P_CALL_EVENT_UNDEFINED 





Undefined 


P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT 


1 


An originating call attempt takes place (e.g. Off-hook event). 


P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT_AUTHORISED 


2 


An originating call attempt is authorised 


P_CALL_EVENT_ADDRESS_COLLECTED 


3 


The destination address has been collected. 


P„CALL_EVENT_ADDRESS_ANALYSED 


4 


The destination address has been analysed. 


P_CALL_EVENT_ORIGINATING_SERVICE_CODE 


5 


Mid-call originating service code received. 


P_CALL_EVENT_ORIGINATING_RELEASE 


6 


A originating call/call leg is released 


P_CALL_EVENT_TERMINATING_CALL_ATTEMPT 


7 


A terminating call attempt takes place 


P_CALL_EVENT_TERMINATING_CALL_ATTEMPT_AUTHORISED 


8 


A terminating call is authorized 


P_CALL_EVENT_ALERTING 


9 


Call is alerting at the call party. 


P_CALL_EVENT_ANSWER 


10 


Call answered at address. 


P_CALL_EVENT_TERMINATING_RELEASE 


11 


A terminating call leg has been released or the call could not 
be routed. 


P_CALL_EVENT_REDIRECTED 


12 


Call redirected to new address; an indication from the network 
that the call has been redirected to a new address (no events 
disarmed as a result of this). 


P_CALL_EVENT_TERMINATING_SERVICE_CODE 


13 


Mid call terminating service code received. 


P_CALL_EVENT_QUEUED 


14 


The Call Event has been queued, (no events are disarmed as a 
result of this) 



EVENT HANDLING RULES: 

The following general event handling rules apply to dynamically armed events: 
When requesting events for one leg; 

• When the monitor mode is set to P_CALL_MONITOR_MODE_DO_NOT_MONITOR all events armed for that 

eventtype are disarmed. The additionalEventCriteria are not taken into account. 

• When requesting two events for the same event type with different criteria and/or different monitor mode the last 
used criteria and monitor mode apply. 

• Events that are not applicable to a leg are refused with exception P_INVALID_EVENT_TYPE. The same 
exception is used when criteria are used that are not applicable to the leg, 

E.g., requesting P_CALL_EVENT_TERMINATING_SERVICE_CODE on an originating leg is refused with 
exception P_INVALID_CRITERIA. 

When P_CALL_EVENT_ORIGINATING_RELEASE is requested with P_BUSY in the criteria the request is 
refused with the same exception. 

When receiving events: 

• If an armed event is met, then it is disarmed, unless explicit stated that it will not to be disarmed. 

• If an event is met that causes the release of the related leg, then all events related to that leg are disarmed . 

• When an event is met on a call leg irrespective of the event monitor mode, then only events belonging to that call 
leg may become disarmed (see table below) . 

• If a call is released, then all events related to that call are disarmed. 

NOTE 1 : Event disarmed means monitor mode is set to DO_NOT_MONITOR. and 
event armed means monitor mode is set to INTERRUPT or NOTIFY.. 
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The table below defines the disarming rules for dynamic events. In case such an event occurs on a call leg the table 
shows which events are disarmed (are not monitored anymore) on that call leg and should be re-armed by 
eventReportReqO in case the application is still interested in these events. 



Event Occurred 




P_CALL_EVENT_UNDEFINED 


Not Applicable 


P„CALL_EVENT_ORIGINATING_CALL_ATTEMPT 


Not applicable, can only be armed as trigger 


P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT_AUTHORISED 


P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT_AUTHORISED 


P J i L L_E y E ^, ^ _j i J J PE S S _G L L E C ^' E J 


P_CALL_EVEKT_ADDRES.S_COLLECTED 


P_C AL L_E VENT_AD D RE S S_ANAL Y S ED 


P_CALL_EVENT_ADDRESS_COLLECTED 
P_CALL_EVENT_ADDRESS_ANALYSED 


P_CALL_EVENT_ALERTING 


P_CALL_EVENT_ALERTING 

P_CALL_EVENT_TERME>JATING_RELEASE with criteria: 

P_USER_NOT_AVAILABLE 

P_BUSY 

P_NOT_REACHABLE 
P_ROUTING_FAILURE 
P_CALL_RESTRICTED 
P_UNAVAILABLE_RESOURCES 


P_CALL_EVENT_ANSWER 


P_CALL_EVENT_ALERTING 
P_CALL_EVENT_ANSWER 

P_CALL_EVENT_TERMINATING_RELEASE with criteria: 

P_USER_NOT_AVAILABLE 

P_BUSY 

P_NOT_REACHABLE 

P_ROUTING_FAILURE 
P_CALL_RESTRICTED 
P_UNAVAILABLE_RESOURCES 

P_NO_ANSWER 


P_CALL_EVENT_ORIGINATING_RELEASE 


All pending network events for the call leg are disarmed 


P_CALL_EVENT_TERMINATING_RELEASE 


All pending network events for the call leg are disarmed 


P_CALL_EVENT_ORIGINATING_SERVICE_CODE 


P_CALL_EVENT_ORIGINATING_SERVICE_CODE *) see NOTE 2 


P_CALL_EVENT_TERMINATING_SERVICE_CODE 


P„CALL_EVENT_TERMINATING_SERVICE_CODE *) see NOTE 2 


NOTE 2: Only the detected service code or the range to which the service code belongs Is disarmed. 
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7.6.2.25 TpAdditionalCallEventCriteria 



Defines the Tagged Choice of Data Elements that specify specific criteria. 





lafl^lement Type 






TpCallEventType 





Tag Element 
Value 


Choice Element 


Choice Element 


P_CALL_EVENT_UNDEFINED 


NULL 


Undefined 


P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT 


NULL 


Undefined 


P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT_AUTHO 
RI SED 


NULL 


Undefined 


P_CALL_EVENT_ADDRESS_COLLECTED 


Tplnt32 


MinAddressLength 


P_CALL_EVENT_ADDRESS_ANALYSED 


NULL 


Undefined 


P_CALL_EVENT_ORIGINATING_SERVICE_CODE 


TpCallServiceCodeSet 


OriginatingServiceCode 


P_CALL_EVENT_ORIGINATING_RELEASE 


TpReleaseCauseSet 


OriginatingReleaseCauseSet 


P_CALL_EVENT_TERMINATING_CALL_ATTEMPT 


NULL 


Undefined 


P_CALL_EVENT_TERMINATING_CALL_ATTEMPT_AUTHO 
RISED 


NULL 


Undefined 


P_CALL_EVENT_ALERTING 


NULL 


Undefined 


P_CALL_EVENT_ANSWER 


NULL 


Undefined 


P_CALL_EVENT_TERMINATING_RELEASE 


TpReleaseCauseSet 


TerminatingReleaseCauseSet 


P_CALL_EVENT_REDIRECTED 


NULL 


Undefined 


P_CALL_EVENT_TERMINATING_SERVICE_CODE 


TpCallServiceCodeSet 


TerminatingServiceCode 


P_CALL_EVENT_QUEUED 


NULL 


Undefined 



7.6.2.26 TpCallEventlnfo 



Defines the Sequence of Data Elements that specify the event report specific information. 



Sequence Element 


Sequence Element 


CallEventType 


TpCallEventType 


AdditionalCallEventlnfo 


TpCallAdditionalEventlnfo 


CallMonitorModc 


TpCallMonitorModc 


CallEventTime 


TpDateAndTime 
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1.^.2.21 TpCallAdditionalEventlnfo 

Defines the Tagged Choice of Data Elements that specify additional call event information for certain types 
of events. 





Tag Element Type 






TpCallEventType 


1 



Tag Elemen^^^^^^^^^^^^J^^Choice Element 
VaiHH^^^^^^^^^^HII^^B Type flHHl 


Choice Element 
Name 


P_CALL_EVENT_UNDEF INED 


NULL 


Undefined 


P_C AL L_E VENT_ORI G I NAT I NG_C ALL_AT TEMP T 


NULL 


Undeimed 


P_CALL_EVENT_ORIGINATING_CALL_ATTEMPT_AUTHORISED 


NULL 


Undefined 


P_CALL_EVENT_ADDRESS_COLLECTED 


TpAddress 


CollectedAddress 


P_CALL_EVENT_ADDRESS_ANALYSED 


TpAddress 


CalledAddress 


P_CALL_EVENT_ORIGINATING_SERVICE_CODE 


TpCallServiceCode 


OriginatingServiceCode 


P_C AL L_E VENT_ORI G I NAT I NG_RE LE AS E 


TpReleaseCause 


OriginatingReleaseCause 


P_CALL_EVENT_TERMINATING_CALL_ATTEMPT 


NULL 


Undefined 


P_CALL_EVENT_TERMINATING_CALL_ATTEMPT_AUTHORISED 


NULL 


Undefined 


P_CALL_EVENT_ALERTING 


NULL 


Undefined 


P_CALL_EVENT_ANSWER 


NULL 


Undefined 


P_CALL_EVENT_TERMINATING_RELEASE 


TpReleaseCause 


TerminatingReleaseCause 


P_CALL_EVENT_REDIRECTED 


TpAddress 


ForwardAddress 


P_CALL_EVENT_TERMINATING_SERVICE_CODE 


TpCallServiceCode 


TenninatingServiceCode 


P_CALL_EVENT_QUEUED 


NULL 


Undefined 



7.6.2.28 TpCallNotificationRequest 



Defines the Sequence of Data Elements that specify the criteria for an event notification 





Sequence Element Type 


Descrlptlon^^^^^^__ 


CallNotif icationScope 


TpCallNotificationScope 


Defines the scope of the notification request. 


CallEventsRequested 


TpCallEventRequestSet 


Defines the events which are requested 



7.6.2.29 TpCallNotificationScope 

Defines a the sequence of Data elements that specify the scope of a notification request. 

Of the addresses only the Plan and the AddrString are used for the purpose of matching the notifications against the 

criteria. 



Sequence Element 
Name 


Sequence Element 
Tvpe 


Description 


DestinationAddress 


TpAddressRange 


Defines the destination address or address range for which the notification is 
requested. 


OriginatingAddress 


TpAddressRange 


Defines the origination address or address range for which the notification is 
requested. 
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7.6.2.30 TpCallNotificationlnfo 



Defines the Sequence of Data Elements that specify the information returned to the application in a Call 
notification report. 



Sequence Elem^^^^^H 


Sequence EI^^^^^^^T 


Description 


■■BHMk. Name ^^^^^H 


Type ^^^^^k 




CallNotificationReport Scope 


TpCallNot if icat ionReportScope 


Defines the scope of the notification report. 


CallAppInf o 


TpCallAppInf oSet 


Contains additional call info. 


C a 1 i V e n t ^ n f o 




Contains tlic event wliicli is lepoitcd. 



7.6.2.31 TpCallNotificationReportScope 



Defines the Sequence of Data Elements that specify the scope for which a notification report was sent. 



Sequence Element 
Name 


Sequence Element 
Type 


Description 


DestinationAddress 


TpAddress 


Contains the destination address of the call. 


OriginatingAddress 


TpAddress 


Contains the origination address of the call 



7.6.2.32 TpNotification Requested 



Defines the Sequence of Data Elements that specify the criteria relating to event requests. 



Sequence Element 


Sequence Element 


AppCallNotif icationRequest 


TpCallNot if icationRequest 


Assignment ID 


Tplnt32 



7.6.2.33 TpNotification RequestedSet 

Defines a numbered Set of Data Elements of TpNotificationRequested. 

7.6.2.34 TpReleaseCause 

Defines the reason for which a call is released. 



Name 


Value 


Description 


p. 


.UNDEFINED 





The reason of release is not known, because no info was received from the network. 


p_ 


_USER_NOT_AVAI LABLE 


1 


The user is not available in the network. This means that the number is not allocated or that the user is 

not registered. 


p_ 


_BUSY 


2 


The user is busy. 


p. 


_NO_ANSWER 


3 


No answer was received 


p. 


_NOT_REACHABLE 


4 


The user terminal is not reachable 


p. 


_ROUT ING_FAI LURE 


5 


A routing failure occurred. For example an invalid address was received 


p. 


_PREMATURE_DISCONNECT 


6 


The user disconnected the call / call leg during the setup phase. 


p. 


.DISCONNECTED 


7 


A disconnect was received. 


p_ 


_CALL_RESTRICTED 


8 


The call was subject of restrictions 


p. 


_UNAVAI LABLE_RE SOURCE 


9 


The request could not be carried out as no resources were available. 


p_ 


_GENERAL_FAI LURE 


10 


A general network failure occurred. 


p_ 


_"IKER_EXPIRY 


11 


The eall / call leg was released because an aeti\ ity timer ex|)iied. 



7.6.2.35 TpReleaseCauseSet 

Defines a Numbered Set of Data Elements of TpCallReleaseCause. 
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7.6.2.36 TpCallLegldentifier 



Defines the Sequence of Data Elements that unambiguously specify the Call Leg object. 





Sequence Element 
Type 


Sequence Element ^^^^^I^^^HI 

Description 


CallLegRef erence 


IpCallLegRef 


This element specifies the interface reference for the callLeg object. 


1 CallLegSessionID 


TpSessionID 


This element specifies the callLeg session ID. 



7.6.2.37 TpCallLegldentifierSet 

Defines a Numbered Set of Data Elements of TpCallLegldentifier. 

7.6.2.38 TpCallLegAttachMechanism 

Defines how a CallLeg should be attached to the call. 



Name 


Value 


Description 


P_CALLLEG_ATTACH_IMPLICITLY 





CallLeg should be attached implicitly to the call. 


P_CALLLE G_AT T ACH_E XPLICITLY 


1 


CallLeg should be attached exphcitly to the call by using the attachMediaReqO operation. This 
allows e.g. the appUcation to do first user interaction to the party before he/she is placed in the 
call. 



7.6.2.39 TpCallLegConnectionProperties 



Defines the Sequence of Data Elements that specify the connection properties of the Call Leg object 



Sequence Element 


Sequence Element 


Sequence Element 


AttachMechanism 


TpCallLegAttachMechanism 


Defines how a CaULeg should be attached to the call. 



7.6.2.40 TpCallLeglnfoReport 

Defines the Sequence of Data Elements that specify the call leg information requested. 



Sequence Element 
Name 


Sequence Element 
Type 




CallLegInf oType 


TpCallLegInf oType 


The type of call leg information. 


CallLegSt art Time 


TpDateAndTime 


The time and date when the call leg was started (i.e. the leg was routed). 


CallLegConnectedToResourceTime 


TpDateAndTime 


The date and time when the call leg was connected to the resource. If no 

resource was connected the time is set to an empty string. 
Either this element is vaUd or the CallCoimectedToAddressTime is vaUd, 
depending on whether the report is sent as a result of user interaction. 


CallLegConnectedToAddressTime 


TpDateAndTime 


The date and time when the call leg was connected to the destination (i.e. 
when the destination answered the call). If the destination did not 
answer, the time is set to an empty string. 
Either this element is vahd or the CaUCoimectedToResourceTime is 
vahd, depending on whether the report is sent as a result of user 
interaction. 


CallLegEndTime 


TpDateAndTime 


The date and time when the call leg was released. 


ConnectedAddress 


TpAddress 


The address of the party associated with the leg. If during the call the 
connected address was received from the party then this is returned, 
otherwise the destination address (for legs connected to a destination) or 
the originating address (for legs connected to the origination) is returned. 


CallLegReleaseCause 


TpReleaseCause 


The cause of the termination. May be present with 
P_CALL_LEG_lNFO_RELEASE_CAUSE was specified. 


CallAppInf o 


TpCallAppInf oSet 


Additional information for the leg. May be present with 
P_CALL_LEG_INFO_APPINFO was specified. 
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7.6.2.41 TpCallLeglnfoType 

Defines the type of call leg information requested and reported. The values may be combined by a logical 'OR' function. 



Name 


Value 


Description ^^^^^H 


P_CALL_LEG_INFO_UNDEFINED 


OOh 


Undefined 


P_CALL_LEG_INFO_TIMES 


Olh 


Relevant call times 


P _C J ,L L_L L G_ ^ ^, t ' 0_1<L L E J , S J , ^ S L 


02h 


Call leg i clcasc cause 


P_CALL_LEG_INFO_ADDRESS 


04h 


Call leg connected address 


P_CALL_LEG_INFO_APPINFO 


08h 


Call leg application related information 



7.6.2.42 TpCallLegSuperviseTreatment 



Defines the treatment of the call leg by the call control service when the call leg supervision timer expires. The values 
may be combined by a logical 'OR' function. 



Name 


Value 


^^^^B Description ^^^^^H 


P_CALL_LEG_SUPERVISE_RELEASE 


Olh 


Release the call leg when the call leg supervision timer expires 


P_CALL_LEG_SUPERVISE_RESPOND 


02h 


Notify the application when the call leg supervision timer expires 


P_CALL_LEG_SUPERVI SE_APPLY_TONE 


04h 


Send a warning tone on the call leg when the call leg supervision timer expires. If call 
leg release is requested, then the call leg will be released following the tone after an 
administered time period 



8 Common Call Control Data Types 



The following data types referenced in this clause are defined in 3GPP TS 29.198-5: 

TpUIInfo 

All other data types referenced but not defined in this clause are connmon data definitions which may be found in 
3GPPTS 29.198-2. 

8.1 TpCallAlertingMechanism 

This data type is identical to a Tplnt32 , and defines the mechanism that will be used to alert a call party. The values 
of this data type are operator specific. 
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8.2 TpCallBearerService 



This data type defines the type of call application-related specific infomation (Q.931: Information Transfer CapabiUty, 
and 3GTS 22.002) 



P_CALL_BEARER_SERVICE_UNKNOWN 





Bearer capability information unknown at this time 


P_CALL_BEARER_SERVICE_SPEECH 


1 


Speech 


P_CALL_BEARER_SERVICE_DIGITAL UNRESTRICTED 


2 


Unrestricted digital information 


P_CALL_BEARER_SERVICE_DIGITAL RESTRICTED 


3 


Restricted digital information 


P_CALL_BEARER_SERVI CE_AUD 1 


4 


3,1 kHz audio 


P_CALL_BEARER_SERVICE_DIGITALUNRESTRICTEDTONES 


5 


Unrestricted digital information with tones/announcements 


P_CALL_BEARER_SERVICE_VIDEO 


6 


Video 



8.3 TpCallChargePlan 



Defines the Sequence of Data Elements that specify the charge plan for the call. 









ChargeOrderType 


TpCallChargeOrderCategory 


Charge order 


Transparent Charge 


TpOctetSet 


Operator specific charge plan specification, 
e.g. charging table name / charging table entry. 
The associated charge plan data will be send 
transparently to the charging records. 

Only appUcable when transparent charging is 

selected. 


ChargePlan 


Tplnt32 


Pre-defined charge plan. Example of the 
charge plan set from which the application can 
choose could be : (0 = normal user, 1 = silver 
card user, 2 = gold card user). 

Only applicable when transparent charging is 
selected. 


Additional Info 


TpOctetSet 


Descriptive string which is sent to the billing 

system without prior evaluation. Could he 
included in the ticl^et. 


PartyToCharge 


TpCallPartyToChargeType 


Identifies the entity or party to be charged for 
the call or call leg. 


PartyToChargeAdditionalInf o 


TpCallPartyToChargeAdditionalInf o 


Contains additional information regarding the 
charged party. 



8.4 TpCallPartyToChargeAdditionallnfo 



Defines the Tagged Choice of Data Elements that identifies the entity or party to be charged. 





Tag Element Type 








TpCallPartyToChargeType 







Tag Element Value 


Choice Element 
Type 




P_CALL_PARTY_ORIGINATlNG 


NULL 


Undefined 


P_CALL_PARTY_DESTINATION 


NULL 


Undefined 


P_CALL_PARTY_SPECIAL 


TpAddress 


CallParty Special 
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8.5 TpCallPartyToChargeType 



Defines the type of call party to charge 





Value 




P_CALL_PARTY_ORIGINATING 





Calling party, i.e. party that initiated the call. For application initiated calls this 
indicates the first party of the call 


P_CALL_PARTY_DESTINATION 


1 


Called party 


P_CALL_PARTY_SPECIAL 


2 


An address identifying e.g. a third party, a service provider 



8.6 TpCallChargeOrder 



Defines the Tagged Choice of Data Elements that specify the charge plan for the call. 





Tag Element Type 











P_CALL_CHARGE_TRANSPARENT 


TpOctetSet 


Transparent Charge 


P_C AL L_CH ARGE_P REDEFINED_SET 


Tplnt32 


ChargePlan 



8.7 TpCallChargeOrderCategory 



Defines the type of charging to be applied 





^Value 










P_CALL_CHARGE_TRANSPARENT 





Operator specific charge plan specification, e.g. charging table name / charging 
table entry. The associated charge plan data will be send transparently to the 
charging records 


P_CALL_CHARGE_PREDEFINED_SET 


1 


Pre-defined charge plan. Example of the charge plan set from which the appUcation 
can choose could be : (0 = normal user, 1 = silver card user, 2 = gold card user). 



8.8 TpCallEndedReport 



Defines the Sequence of Data Elements that specify the reason for the call ending. 



Sequence Element Name 


Sequence Element Type 




CallLegSessionID 


TpSessionID 


The leg that initiated the release of the call. 
If the call release was not initiated by the leg, then this value is set to -1. 


Cause 


TpReleaseCause 


The cause of the call ending. 



8.9 TpCallError 



Defines the Sequence of Data Element s that specify the additional information relating to a call error. 



i 



yice Element l^j— 



ErrorTime 



ll§f riiirnr e Element i 

TpDateAndTime 



ErrorType 



TpCallError Type 



AdditionalErrorInf o 



TpCallAdditionalErrorInf o 
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8.10 TpCallAdditionalErrorlnfo 



Defines the Tagged Choice of Data Elements that specify additional call error and call error specific 
information. This is also used to specify call leg errors and information errors. 











TpCallErrorType 

















P_C AL L_E RROR_UND E F I NE D 


NULL 


Undefined 


P_CALL_ERROR_INVALID_ADDRESS 


TpAddressError 


CallErrorlnvalidAddress 


P_CALL_ERROR_INVAL I D_S TATE 


NULL 


Undefined 


P_CALL_ERROR_RESOURCE_UNAVAILABLE 


NULL 


Undefined 



8.11 TpCallErrorType 



Defines a specific call error. 



Name ^^^^ 


Value 


Description 


P_CALL_ERROR_UNDEFINED 





Undefined; the method failed or was refused, but no specific reason can be given. 


P_CALL_ERROR_INVALID_ADDRESS 


1 


The operation failed because an invalid address was given 


P_CALL_ERROR_INVAL I D_S TATE 


2 


The call was not in a valid state for the requested operation 


P_CALL_ERROR_RESOURCE_UNAVAILABLE 


3 


There are not enough resources to complete the request successfully 



8.12 TpCalllnfoReport 



Defines the Sequence of Data Elements that specify the call information requested. Information that was not 

requested is invalid. 







M^BKKKk Description j/^g/gggggd 


Callinf oType 


TpCalllnfoType 


The type of call report. 


CalllnitiationSt art Time 


TpDateAndTime 


The time and date when the call, or foUow-on call, was 
started. 


CallConnectedToResourceTime 


TpDateAndTime 


The date and time when the call was connected to the 

resource. 

This data clement is only \'alid when information on user 
interaction is reported. 


CallConnectedToDestinationTime 


TpDateAndTime 


The date and time when the call was connected to the 
destination (i.e., when the destination answered the call). If 
the destination did not answer, the time is set to an empty 
string. 

This data element is invalid when information on user 
interaction is reported with an intermediate report. 


CallEndTime 


TpDateAndTime 


The date and time when the call or follow-on call or user 
interaction was terminated. 


Cause 


TpReleaseCause 


The cause of the termination. 



A calUnfoReport will be generated at the end of user interaction and at the end of the connection with the associated 
address. This means that either the destination related information is present or the resource related information, but not 
both. 
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8.13 TpCalllnfoType 

Defines the type of call information requested and reported. The values may be combined by a logical 'OR' function. 





Value 




P_CALL_INFO_UNDEFINED 


OOh 


Undefined 


P_CALL_INFO_TIMES 


Olh 


Relevant call times 


P_CALL_INFO_RELEASE_CAUSE 


02h 


Call release cause 



8.14 TpCallLoadControlMechanism 

Defines the Tagged Choice of Data Elements that specify the apphed mechanism and associated parameters. 



Tag Element Type 

TpCallLoadControlMechanismType 



Tag Element Value 


Choice Element Type 


Choice Element Name 


P_CALL_LOAJ_CO;, i ROL_t'ER_i^ i EKvAL 


±'pCa^ ±LoaaCont r o± xnt ervalKat e 


Call^cadCcntrclz'erlnterval 



8.15 TpCallLoadControllntervalRate 



Defines the call admission rate of the call load control mechanism used. This data type indicates the interval (in 
milliseconds) between calls that are admitted. 



Name 


^^^^^^^^^^^^^^^^^^HEescrlptlon ^^^^^H 


P_CALL_LOAD_CONTROL_ADMIT_NO_CALLS 





Infinite interval 
(do not admit any calls) 




1 - 6()(H)() 


Duration in milliseconds 



8. 1 6 TpCallLoadControlMechanismType 



Defines the type of call load control mechanism to use. 



Name 


Value 




P_CALL_LOAD_CONTROL_PER_INTERVAL 





^^^^^^^^^^^^^^^^^^^^^^ 



8. 1 7 TpCallMonitorMode 



Defines the mode that the call will monitor for events, or the mode that the call is in following a detected event. 



P_CALL_MONITOR_MODE_INTERRUPT 





The caU event is intercepted by the call control service and call processing is 
interrupted. The application is notified of the event and call processing resumes 

following an appropriate API call or network event (such as a call release) 


P_CALL_MONITOR_MODE_NOTIFY 


1 


The call event is detected by the call control service but not intercepted. The 
appUcation is notified of the event and call processing continues 


P_CALL_MONI TOR_MODE_DO_NOT_MONI TOR 


2 


Do not monitor for the event 
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8.18 TpCallNetworkAccessType 

This data defines the bearer capabilities associated with the call. (3G TS 24.002) This information is network operator 
specific and may not always be available because there is no standard protocol to retrieve the information. 



P_CALL_NETWORK_ACCE S S_TYPE_UNKNOWN 





Network type information unknown at this time 


P_CALL_NETWORK_ACCESS_TYPE_POT 


1 


POTS 


P_CALL_NETWORK_ACCE S S_T YPE_I SDN 


2 


ISDN 


P_CALL_NETWORK_ACCESS_TYPE_DIALUPINTERNET 


3 


Dial-up Internet 


P_CALL_NETWORK_ACCESS_TYPE_XDSL 


4 


xDSL 


P_CALL_NETWORK_ACCESS_TYPE_WIRELESS 


5 


Wireless 



8.19 TpCallPartyCategory 



This data type defines tlie category of a calling party. (Q.763: Calling Party Category / Called Party Category) 



Name 


Value 


Description 


P_CALL_PARTY_CATEGORY_UNKNOWN 





calling party's category unknown at this time 


P_CALL_PARTY_CATEGORY_OPERATOR_F 


1 


operator, language French 


P_CALL_PARTY_CATEGORY_OPERATOR_E 


2 


operator, language English 


P_CALL_PARTY_CATEGORY_OPERATOR_G 


3 


operator, language German 


P_CALL_PARTY_CATEGORY_OPERATOR_R 


4 


operator, language Russian 


P_CALL_PARTY_CATEGORY_OPERATOR_S 


5 


operator, language Spanish 


P_CALL_PARTY_CATEGORY_ORDINARY_SUB 


6 


ordinary caUing subscriber 


P_CALL_PARTY_CATEGORY_PRIORITY_SUB 


7 


calUng subscriber with priority 


P_CALL_PARTY_CATEGORY_DATA_CALL 


8 


data call (voice band data) 


P_CALL_PARTY_CATEGORY_TEST_CALL 


9 


test call 


P_CALL_PARTY_CATEGORY_PAYPHONE 


10 


payphone 



8.20 TpCallServiceCode 

Defines the Sequence of Data Elements that specify the service code and type of service code received during 
a call. The service code type defines how the value string should be interpreted. 



CallServiceCodeType 


TpCallServiceCodeType 


ServiceCode Value 


TpString 



8.21 TpCallServiceCodeSet 

Defines a Numbered Set of Data Elements of TpCallServiceCode. 
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8.22 TpCallServiceCodeType 



Defines the different types of service codes that can be received during the call. 





Value 




P_CALL_SERVICE_CODE_UNDEFINED 





The type of service code is unknown. The corresponding string is operator 

specific. 


P CALL SERVICE CODE DIGITS 




The user entered a digit sec|uence during the call. The corresponding string 
is an ASCn representation of the received digits. 


P_CALL_SERVICE_CODE_FACILITY 


2 


A faciUty information element is received. The corresponding string 
contains the facility information element as defined in ITU Q.932 


P_CALL_SERVICE_C0DE_U2U 


3 


A user-to-user message was received. The associated string contains the 
content of the user-to-user information element. 


P_CALL_SERVICE_CODE_HOOKFLASH 


4 


The user performed a hookflash, optionally followed by some digits. The 
corresponding string is an ASCII representation of the entered digits. 


P_CALL_SERVICE_CODE_RECALL 


5 


The user pressed the register recall button, optionally followed by some 
digits. The corresponding string is an ASCII representation of the entered 
digits. 



8.23 TpCallSuperviseReport 



Defines the responses from the call control service for calls that are supervised. The values may be combined by a 
logical 'OR' function. 





Value 


.^^^^ DescriDtlon .^^^mh 


P_CALL_SUPERVISE_TIMEOUT 


Olh 


The call supervision timer has expired 


P_CALL_SUPERVISE_CALL_ENDED 


02h 


The call has ended, either due to timer expiry or 

call party release. In case the called party 
disconnects but a follow-on call can still be made 
also this indication is used. 


P_CALL_SUPERVISE_TONE_APPLIED 


04h 


A warning tone has been applied. This is only sent 
in combination with 
P_CALL_SUPERVISE_TIMEOUT 


P_CALL_SUPERVISE_UI_FINISHED 


08h 


The user interaction has finished. 



8.24 TpCallSuperviseTreatment 



Defines the treatment of the call by the call control service when the call supervision timer expires. The values may be 
combined by a logical 'OR' function. 





Value 


Description 


P_CALL_SUPERVISE_RELEASE 


Olh 


Release the call when the call supervision timer 
expires 


P_C AL L_S UP ERVI S E_RE S P OND 


02h 


Notify the application when the call supervision 
timer expires 


P_CALL_SUPERVISE_APPLY_TONE 


04h 


Send a warning tone to the originating party when 
the call supervision timer expires. If call release is 
requested, then the call will be released following 
the tone after an administered time period 
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8.25 TpCallTeleService 

This data type defines the tele-service associated with the call. (Q.763: User Teleservice Informatioii, Q.931: High 
Layer CompatibiUty Information, and 3G TS 22.003) 



P_CALL_TELE_SERVICE_UNKNOWN 





Teleservice information unknown at this time 


P_CALL_TELE_SERVICE_TELEPHONY 


1 


Telephony 


P_CALL_TELE_SERVICE_FAX_2_3 


2 


Facsimile Group 2/3 


P_CALL_TELE_SERVICE_FAX_4_I 


3 


Facsimile Group 4, Class I 


P_CALL_TELE_SERVICE_FAX_4_I I_1 1 1 


4 


Facsimile Group 4, Classes U and III 


P_CALL_TELE_SERVICE_VIDEOTEX_SYN 


5 


Syntax based Videotex 


P_CALL_TELE_SERVICE_VIDEOTEX_INT 


6 


International Videotex interworking via gateways or interworking 
units 


P_CALL_TELE_SERVICE_TELEX 


7 


Telex service 


P_CALL_TELE_SERVICE_MHS 


8 


Message HandUng Systems 


P_CALL_TELE_SERVICE_OSI 


9 


OSI application 


P_CALL_TELE_SERVICE_FTAM 


10 


FT AM application 


P_CALL_TELE_SERVICE_VIDEO 


11 


Videotelephony 


P_CALL_TELE_SERVICE_VIDEO_CONF 


12 


Videoconferencing 


P_CALL_TELE_SERVICE_AUDIOGRAPH_CONF 


13 


Audiographic conferencing 


P_CALL_TELE_SERVICE_MULTIMEDIA 


14 


Multimedia services 


P_CALL_TELE_SERVICE_CS_INI_H221 


15 


Capability set of iiutial channel of H.221 


P_CALL_TELE_SERVICE_CS_SUB_H221 


16 


Capability set of subsequent channel of H.221 


P_C AL L_TE LE_SERVICE_CS_INI_CALL 


17 


Capability set of initial channel associated with an active 3,1 kHz 
audio or speech call. 


P_CALL_TELE_SERVICE_DATATRAFFIC 


18 


Data traffic. 


P_CALL_TELE_SERVICE_EMERGENCY_CALLS 


19 


Emergency Calls 


P_CALL_TELE_SERVICE_SMS_MT_PP 


20 


Short message MT/PP 


P_C J iL L__'ELL_SL1< 1 C L_S :-:S_:-:0_P P 




Short message MO/PP 


P_CALL_TELE_SERVICE_CELL_BROADCAST 


22 


Cell Broadcast Service 


P_CALL_TELE_SERVICE_ALT_SPEECH_FAX_3 


23 


Alternate speech and facsimile group 3 


P_CALL_TELE_SERVICE_AUT0MATIC_FAX_3 


24 


Automatic Facsimile group 3 


P_CALL_TELE_SERVICE_VOICE_GROUP_CALL 


25 


Voice Group Call Service 


P_CALL_TELE_SERVICE_VOICE_BROADCAST 


26 


Voice Broadcast Service 



8.26 TpCallTreatment 



Defines the Sequence of Data Elements that specify the treatment for calls that will be handled only by the 
network (for example, call which are not admitted by the call load control mechanism). 



CallTreatmentType 


TpCallTreatment Type 


ReleaseCause 


TpReleaseCause 


AdditionalTreatment Inf o 


TpCallAdditionalTreatmentInf o 
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8.27 TpCallTreatmentType 



Defines the treatment for calls that will be handled only by the network. 





Value 




P_CALL_TREATMENT_DEFAULT 





Default treatment 


P_CALL_TREATMENT_RELEASE 


1 


Release the call 


P_CALL_TREATMENT_S I AR 


2 


Send information to the user, and release the 
call (Send Info & Release) 



8.28 TpCallAdditionalTreatmentlnfo 



Defines the Tagged Choice of Data Elements that specify the information to be sent to a call party. 





Tag Element Type 






TpCallTreatmentType 





P_ 


_CALL_ 


.TREATMENT. 


.DEFAULT 


NULL 


Undefined 


P_ 


_CALL_ 


.TREATMENT. 


.RELEASE 


NULL 


Undefined 


P_ 


_CALL_ 


.TREATMENT. 


.STAR 


TpUIInfo 


Inf ormationToSend 



8.29 TpMediaType 



Defines the media type of a media stream. The values may be combined by a logical 'OR' function. 



Name 


Value 


Description 




1 


Audio stream 


P_VIDEO 


2 


Video stream 


P_DATA 


4 


Data stream (e.g., T.120) 
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Annex A (normative): 

OMG IDL Description of Call Control SCF 

The OMG IDL representation of this interface specification is contained in text files (contained in archive 
2919804IDL.ZIP) which accompany the present document. 
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